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When someone first asked me about 
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be a joke. 
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I’m not laughing anymore. Joe Campbell, the English professor at Berkeley who had 
asked me about security, explained that if UNIX was to be used by businesses, security 
was essential. This was news to me, as I was coming from a programming perspective 
where security was “interesting” because of the clever ways of abusing system utilities to 
gain privileges. 

Joe was right, but not just about UNIX. Our computer systems and networks are now the 
backbone of business, whether you are ordering fast food, making stock trades, flying in 
airplanes, or going in for heart surgery. But what was true in the early eighties when I was 
asked this question is still true today: Our computer systems and networks are vulnerable. 

Scripts exist that will permit an attacker to connect to a network service and fool it into 
running a shell - a stack overrun. Software exists for both UNIX and NT systems for 
efficiently guessing passwords, along with tricks and techniques for acquiring encrypted 
passwords. You can find exploits using Web search engines that will grant you root priv¬ 
ileges on UNIX systems. All you need to do is get interactive use of the system, upload 
and run the exploit script. 

Bill Cheswick's keynote speech at the Seventh USENIX Security Symposium in January 
1998 included pictures of castles and fortifications from around the world to make sev¬ 
eral important points about security. The best fortifications offered protection in depth. 
The castle (or the Great Wall) would be located on top of a hill or, better yet, a sheer 
bluff. The next line of defense would be a difficult-to-scale wall, topped by embrasures 
for the defenders. The castle gate would actually be a series of gates, connected by tun¬ 
nels or narrow passageways. If the attackers got through the outer gate, they would find 
themselves in these enclosed spaces facing well-protected defenders with arrows, spears, 
and even boiling oil. And still more gates to batter down. 

In his talk, Bill described how Robert the Bruce took Edinburgh castle. He led a small 
group of men up a trail that was used by one of the defenders to reach his girlfriend in 
the small town below. A guard spotted the group, but just laughed at them because they 
were outside the wall. Robert and his men scaled the wall, went to the front gates, and 
threw them open after overcoming the guards. An inside attack. Bill pointed out that 
many other fortifications had been overthrown through the help of insiders. 

The common wisdom about computer security is that most security incidents have an 
internal origin. This was true for many years, but apparently not anymore. The 1997 
CSI/FBI security survey reported that sites reported the Internet as equivalent to inter¬ 
nal sources for security events last year (<http://www.gocsi.com>). Financial losses were up 
from the previous year by 36%, and the most serious losses were from unauthorized use 
and theft of proprietary information. 
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The time for ignoring security has long since passed. People used to rob banks because 
that’s where the money was. Today, value is on line, in our computer systems, in the 
form of information and cash equivalents. The layered defenses that Bill described have 
become critical to our computer and network infrastructure. This special issue of ;login: 
attempts to add to the body of knowledge about improving security, by pointing out 
weaknesses, new defenses, and future directions. Included are the reports from confer¬ 
ence scribes and nine additional articles. 

We include a speech about the future of security from a vendor’s viewpoint that Dan 
Geer gave at a security conference. Actually, Dan goes quite a bit further in his predic¬ 
tions, including having IBM taking over the desktops and Microsoft the high end. 

Before you get too upset, I suggest you start reading. 

David Martin writes a lively and useful article about anonymity on the net. I had heard 
of some of the projects, but David has done a lot of research in this area and shares it 
with us, along with pointers to sites that let us use existing services or add to such ser¬ 
vices as the Mixmaster. Creating true, bidirectional, anonymity turns out to be difficult 
but arguably useful. 

Peter Brundrett of Microsoft contributes an article about the Kerberos version 5 imple¬ 
mentation that will be found in NT version 5. His article provides an overview of the 
authentication mechanisms used in all NT versions and of how these mechanisms will 
be supported using Kerberos for authentication. Brundrett explains that NT systems, 
because of their reliance on sets of security identifiers (SIDs) for naming, will not be 
completely compatible with UNIX-based Kerberos systems. 

Elias Levy, also known as Aleph One, the moderator of the Bugtraq mailing list, shares 
some information about recent network-based attacks with us. Aleph One has done 
research into finding patches, configuring routers, and tuning operating systems to pre¬ 
vent these attacks (to the degree that it is possible). 

Matt Curtin and Justin Dolske write about the great DES challenge and the tools used 
to launch an Internetwide “crack.” In January 1997, RSA issued several challenges, all 
involving discovering passwords of varying lengths. The DES challenge meant cracking 
a 56-bit key and during the process involved over 78,000 unique IP addresses (which 
does not translate directly in a count of hosts). 

Jon Meek describes some software he wrote to provide new options for authenticating 
Web users. His software is designed to work as an Apache Web server module and sup¬ 
ports UNIX passwords for two NIS domains, NT domain passwords for two domains, 
VAX/VMS passwords, SecurlD, and standard Web authentication. 

Scott Guthery provides an excellent article explaining some of the history and present 
and future uses of smart cards. Smart cards have the potential to become the ubiquitous 
token for identification and the keepers of our private keys. 

Yair Frankel and Moti Yung share with us some of their work in the field of split keys 
used in certification authorities (CAs). If a business entity is controlled by many com¬ 
panies, it makes sense to distribute a private key over all of the companies involved. 
Frankel and Yung discuss techniques for splitting keys as an attempt to improve trust 
and reduce fraud. 

Chris Lalonde writes a software review of Network Flight Recorder. Lalonde is an obvi¬ 
ously enthusiastic user of NFR, and his article provides a quick tutorial in using it to 
collect data from a network. 
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This issue’s reports focus on the 
Seventh USENIX Security 
Symposium, held in San Antonio, TX, 
on January 26-29, 1998. 

Our thanks to the Summarizers: 

Kevin Fu 
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Gus Shaffer 

<shafferz@umich.edu> 

Jim Simpson 

<freyjs@umich.edu> 

<dugsong@monkey.org> 

Our thanks to the Photographer: 

<darrenr@cyber.com.au> 

Abstracts of the refereed papers 
presented at the symposium are at 
<http://www.usenix.org/publications/library/ 
proceedings/sec98/>. 

USENIX members may also access 
the full text. 
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Seventh USENIX 
Security Symposium 

SAN ANTONIO, TEXAS 


lanuary 26-29,1998 


KEYNOTE ADDRESS 
Security Lessons From All Over 

Bill Cheswick, Lucent Technologies, 
Bell Labs 

Summary by Dug Song 

In a freewheel¬ 
ing, “experimen¬ 
tal” talk deliv¬ 
ered to an audi¬ 
ence plenty eager 
to be his guinea 
pigs, Cheswick 
Bill Cheswick offered several 

keen and often humorous insights on the 
topic of security from a variety of disci¬ 
plines, including architecture, biology, 
chemistry, and military history. 

In case study after case study, he illustrat¬ 
ed how security paradigms, exploits, and 
strategies cross every imaginable bound¬ 
ary; how the concepts of perimeter 
defense, backdoors, trojan horses, and 
bluffing recur throughout history. He 
also highlighted security strategies we can 
learn from nature, such as multilayered, 
multifaceted defenses and the advantages 
of diversity. 

This fascinating, multidisciplinary histor¬ 
ical perspective on security from one of 
the “seven avatars of the Internet” includ¬ 
ed 155 slides in 1.5 hours. You can find 
more information at <http://cm.bell-labs.com/ 
who/ches/ppt/universal.ppt> and 
<http://cm.bell-labs.com/who/ches/>. 

REFEREED PAPERS TRACK 

Session: Architecture 
Summaries by Jim Simpson 

Steve Bellovin of AT&T Labs - Research 
chaired this session, where two papers 
involving the design and implementation 


of responses to security issues were pre¬ 
sented. The first paper concerned adap¬ 
tive security policies for systems that sep¬ 
arate the policy in a Security server that 
the kernel must then enforce. The second 
talked about a new wide-area authentica¬ 
tion and access control system for distrib¬ 
uted applications, CRISIS. CRISIS is cur¬ 
rently used as the security subsystem of 
WebOS, a system that lends itself to 
wide-area implementation of distributed 
applications through extensions of oper¬ 
ating system functions like security, 
resource management, and remote 
process execution. 

A Comparison of Methods for 
Implementing Adaptive Security Policies 

Michael Carney and Brian Loe, 

Secure Computing Corporation 

Loe started off his talk by explaining that 
this paper stemmed from a project called 
Experience with Adaptive Security 
Policies, funded by Bell Labs, which was a 
followup to an earlier program called 
Experimentation with Adaptive Security 
Policies. Some of the methods discussed 
in this paper were done in the original 
projects. Some of the goals of the pro¬ 
gram were to look at how to change poli¬ 
cies in systems that were relatively large. 

Two types of adaptive security include: 

■ discretionary access control 

■ mandatory access control 

There are small things you might do with 
discretionary access that can be done in 
relatively simple ways, but the sponsors 
of this particular program were more 
interested in things like globally changing 
the security lattice in a system with mul¬ 
tilevel security and, in a nonmilitary situ¬ 
ation, defining 
ways that rules 
change when 
subjects act on 
objects. 

The motivation 
behind this 
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comes from the idea that you have a large 
organization with some sort of security 
policy and a computer system with 
another security policy. You want to make 
sure that there’s a correspondence 
between what the organization wants and 
what the actual computer does. Most 
organizations have security policies that 
change over time, and you want to make 
sure the computer system can change as 
well, hence the word adaptive. 

Examples of when you might want 
adaptive security policies include the 
following: 

■ Upon intruder detection, you could 
harden the policy. 

■ When important information becomes 
less critical, you might relax the policy. 

■ As a banking example, using both, after 
business hours you could harden the 
policy but during business hours, you 
could relax relax the policy so work 
could get done. 

■ A timed release of information could 
be based on whom its being distrib¬ 
uted to. 

■ In a certain task- or process-based pol¬ 
icy where a data item is going through 
a pipeline, and processes A, B, and C 
have to do something specific to that 
item, but in a certain order, you might 
have a permission set that changes each 
time the data item is manipulated. 

■ A Chinese Wall policy process has 
access to a number of data items 
belonging to one class, and you want to 
restrain the flow of information from 
one data item to another. 

■ In role-based policies, something 
might operate in different roles. What 
do you do when those roles overlap? 

Implementations were done on the 
DTOS system; if you want more informa¬ 
tion about DTOS, there was a paper pre¬ 
sented about it in 1995, and there was a 
pointer to it in this particular paper. This 
project originally started with a basic 
security architecture they were working 
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with that was then abstracted through 
various changes. The basic security policy 
involves a set of processes trying to 
request services from the kernel that does 
not know what the security policy is. The 
kernel then forwards a request to a 
Security server that has the policy loaded 
at boot-time from some database. The 
server then reports the permissions to the 
kernel, which enforces them. Essentially, 
the kernel queries the server with a 
“Mother, may I?” and is totally ignorant 
of what’s going on. 

This was slightly abstracted by adding a 
policy engine to the back-end. This policy 
engine makes all the security decisions 
for the kernel. In some cases, the 
enforcers of these decisions may not even 
be the kernel; they might be fileservers. 
Still, the basic architecture is the same: 
like the kernel in the previous example, 
they know nothing about the policies 
because that information is located in the 
engine. They just enforce them. The 
engine consists of three pieces: 

■ the server/daemon itself, which the 
enforcer sends queries to 

■ the database that the server uses upon 
boot-up containing policies 

■ the interface to the enforcer 

A common question involves who con¬ 
trols the interface to the enforcer. A few 
variables have to be taken into account 
before that question can be answered. In 
the first example, there was simply one 
Security server. However, there might be 
multiple servers, and these servers might 
have to deal with databases of different 
complexities. 

There are four methods for dealing with 
these variables when implementing adap¬ 
tive security policies; the first three meth¬ 
ods deal solely with one Security server 
answering at a time, and the fourth deals 
with having multiple Security servers 
answering queries: 

■ Reload policy: a Security server might 
have more than one database and sim¬ 


ply load the new policy from a differ¬ 
ent database. 

■ Expand database: make the database a 
little more complex and add logic to 
the Security server. 

■ Hand off control: you can have sepa¬ 
rate Security servers that hand off con¬ 
trol over the interface as to who is 
answering the queries the kernels have. 

■ Hierarchy of servers: multiple servers 
divide up the responsibility for answer¬ 
ing policy questions. 

The details of implementation are gone 
over in the paper, and Loe decided to skip 
over them to save some time. However, 
he did decide to go over the implementa¬ 
tion of the last method involving a hier¬ 
archy of servers. The way this was imple¬ 
mented is that you have various processes 
out in user space, they are trying to ask 
the kernel questions, and the kernel has 
some mapping from these processes into 
the hierarchy. That is, processes 1 
through 10 may all refer to server 0, so 
when they ask the kernel, the kernel 
knows which server to talk to. This is 
more or less a process-oriented security 
policy, making it localized, as opposed to 
being a global policy for all processes. 

Because there are several different meth¬ 
ods, they decided to evaluate them in a 
trade-off study using five different com¬ 
parison criteria: 

■ Policy flexibility: how much can the 
policy change over a transition? 

■ Functional flexibility: transitions trans¬ 
parent? Do things break on users? 

■ Security: are there any flaws or holes 
because of an adaptive policy? 

■ Reliability: is this a reliable method of 
transition? 

■ Performance: not much of an issue for 
them, so it wasn’t gone over in detail 

A hierarchy of servers allows for a great 
amount of policy flexibility; the other 
three methods don’t fare as well. The 
same holds true for functional flexibility. 
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When you reload new policies in existing 
servers, things are going to break on 
users. There are ample concerns when it 
comes to the question of security: how 
are the mechanisms for transition con¬ 
trolled? Is there some way for an agent to 
trigger one of the mechanisms? Do you 
know what the current policy is? A hier¬ 
archy of servers doesn't fare as well in this 
category because with a single point of 
control, you can get a better sense of 
what the security issues are. With many 
servers, you have to worry about many 
more problems. Finally, reliability issues 
seemed good over all cases except for 
hand off control, because it was prone to 
deadlock. 

In summary, if you are trying to imple¬ 
ment a system where small policy 
changes will be made, use a more light¬ 
weight solution. If you need more func¬ 
tional flexibility, you should look at a 
more robust solution, like a hierarchy of 
servers. 

There were only a few questions, one 
being: If you load a new policy, as in 
option 1, how do you know you can han¬ 
dle it? 

Most changes have to be predefined, and 
if you’re using an implementation where 
you just reload the policy, changes will be 
minimal. 

The CRISIS Wide Area Security 
Architecture 

Eshwar Belani and Amin Vahdat, 
University of California, Berkeley, 
Thomas Anderson, University of 
Washington, Seattle, Michael Dahlin, 
University of Texas, Austin 

People often ask what CRISIS stands for 
Vahdat said it indeed was an acronym 
at one point, but it was so forced and 
contrived that it’s since been dropped, 
and they now use a diagram to explain 
CRISIS. Because people in Washington 
and California worked on this project, it 
is only natural they might be concerned 
with wide-area security. 



Wide-area appli¬ 
cations are part 
of WebOS pro¬ 
ject, but WebOS 
didn’t have a 
security system, 
so they couldn’t 
really deploy it. 
They decided to implement a system, but 
found that current security implementa¬ 
tions aren’t tailored very well to wide- 
area applications. 

Why is it important to have security in 
wide-area applications? 


Amin Vahdat 


■ the recent introduction of remote code, 
like Java and agents 

■ poor connectivity on the net 

■ lack of trust among those in a wide 
area 


A very useful example that implements 
this sort of wide-area trust mechanism is 
something called Rent-A-Server. Rent-A- 
Server is a system that allows overloaded 
Web servers to replicate themselves over a 
wide area in response to excessive client 
requests. An overloaded Web server 
would need to contact another server and 
have it execute a copy of the Web server 
and thus offload its excess. 


There are a few security issues involving 
Rent-A-Server: 

■ Remote process execution: When a sur¬ 
rogate agrees to run, it would still like 
some guarantee it gets decent code. 

■ Authorization: How do you prove 
who’s making a request? How do you 
then determine if that person can run a 
Web server on a surrogate. 

■ Secure access to sensitive data: You 
want to be sure you have to subvert 
more than one node to get access to 
sensitive data. 

In a wide area, it’s also good to have a 
fine-grained transfer of rights. Short¬ 
term local rights are ideal for dealing 
with this; you want to avoid modifying 
access control lists to avoid errors caused 


by things like slow links in conjunction 
with invalidating central authorities. 

Here are a few other applications they 
targeted: 

■ SchoolNet is a mechanism allowing 
students in various schools to commu¬ 
nicate with each other. Issues include 
how they authenticate to each other 
and how they talk to one another with¬ 
out publishing a list of members that 
can be talked to. 

■ Wide-area collaboration includes 
development of joint source code. How 
do you securely access the code from 
one tree from several different places? 

More applications are included in the 
paper. 

Given these issues and their require¬ 
ments, they looked at a number of alter¬ 
natives before setting out to build their 
own system: 

■ using a secure login system giving 
everyone accounts (But this has no 
fine-grained control over access rights 
and has the overhead of having to be 
done everywhere.) 

■ Kerberos (But this requires synchro¬ 
nous communication whenever you 
wish to set up secure communication 
and doesn’t scale well.) 

■ SPKI (But this doesn’t take into 
account the availability of remote 
code.) 

Major components of this new system 
are: 

■ transfer certificates - lightweight revo¬ 
cable capabilities that allow for delega¬ 
tion and application of rules and sup¬ 
port systems for fine-grained rights 
transfer 

■ flexible support for trade-offs - securi¬ 
ty vs. performance vs. availability 
through caching 

■ revocation being a first class operation 
both in common and exceptional cases 
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■ preparing requests - simplifies 
accountability, all the terms specifying 
whether or not request should be 
authorized are in request 

On each node in CRISIS, there is a secu¬ 
rity manager responsible for mapping 
process IDs running on that node to a set 
of privileges that describe all the rights 
associated with that running process. The 
security manager also periodically con¬ 
tacts a Certification Authority and an 
On-Line Agent (OLA) to describe these 
privileges. They used the X.509 certificate 
format along with SSL for communica¬ 
tion. The certificates are public-key based 
and have a dual-endorsement mechanism 
where CAs sign identity certificates with 
a long time-out. These are left offline, 
because offline entities are harder to 
attack. The OLA signs certificates with 
shorter time-outs. 

Three problems exist in building this: 

1. Fine-grained rights transfer. This is 
achieved in CRISIS with transfer cer¬ 
tificates. This simplified implementa¬ 
tion of delegation is necessary because 
there will be different levels of trust for 
different nodes. 

2. Mutual authentication. A hybrid ACL 
capability approach for authentication 
is used in CRISIS. ACLs maintain a list 
of authorized principals, and transfer 
certificates grant certain capabilities for 
certain principals. This allows you to 
avoid modifying ACLs. The reference 
monitor is responsible for validating 
time, ensuring that every principal 
along the chain of transfer is trusted 
and that all organizations endorsing 
principals are trusted. 

3. Revoking rights. A currently trusted 
server should not be able to come back 
in two weeks and access data. 
Revocation is a first class operation in 
CRISIS, so all you need to do is inform 
the online agent responsible for 
endorsing a particular certificate that 
the certificate should no longer be 
endorsed. Because a transfer certificate 


can be cached for the time-out of the 
online agent, you might revoke some¬ 
thing that someone has cached and that 
is still valid. The solution to this is setting 
the time-out to be shorter. 

A problem that illustrates these solutions 
is as follows: say theres an overloaded 
Web server in Berkeley that wishes to 
enlist the help of a server in Texas. The 
Berkeley server signs a transfer certificate 
stating that a certain privilege for access¬ 
ing the transfer database is granted to 
Texas. Texas transmits two certificates, 
one being an identity certificate saying 
that some CA says that the key of that 
certificate speaks for Texas, and a transfer 
certificate that says Berkeley says that 
Texas can access the database. The refer¬ 
ence monitor is then able to validate this, 
and the ACL contains only the entry for 
Berkeley. When the session is finished, 
Berkeley informs the OLA that it should 
no longer endorse the transfer certificate 
for Texas. 

They wanted to build CRISIS as some¬ 
thing that would be compatible with 
existing applications, so it’s built as a 
user-level security manager and as a 
library that can be linked into applica¬ 
tions. Actual implementations of these 
systems are gone over further in the 
paper; these include accessing remote 
files and running remote jobs. 

WebOS can be found at: 
<http://now.cs.berkeley.edu/WebOS>. 

There were a few questions, including: 
What is performance like? 

The paper includes numbers. They found 
that performance is limited by the 
encryption/decryption, but in the com¬ 
mon case, this is quite fast because they 
can cache certificates. You’re thus limited 
by the performance of the network. 

What happens if the OLA is killed off? 

If the OLA is killed off, endorsements can 
no longer happen after the time-out, and 
revocation happens by default. 


Session: Intrusion Detection 
Summaries by Kevin Fu 

Bro: A System for Detecting Network 
Intruders in Real-Time 

Vern Paxson, Lawrence Berkeley 
National Laboratory 

Named for its Orwellian potential for pri¬ 
vacy violations, Bro detects intrusions by 
passively monitoring network traffic. 
Particular traffic patterns cause a monitor 
to make intrusion announcements in 
realtime. Vern is a member of the LBNL 
Network Research Group and the author 
of flex, a program to generate a lexical 
analyzer for the front end of compilers. 
Developing Bro since 1995, Vern easily 
earned the best paper award. 

Bros design considers seven goals: high¬ 
speed, large-volume monitoring; resis¬ 
tance from dropping packets; realtime 
notification; separation of mechanism 
from policy; extensibility; avoidance of 
simple policy mistakes; and tolerance for 
attacks on the monitor. Vern gave the 
example of the large LBNL network in 
which security needs not be airtight, but 
intrusions must be detectable. Offline 
intrusion detection has its own applica¬ 
tions, but it is nowhere near as good as 
realtime notification. Vern separates 
mechanism from policy to easily allow 
policy changes in the future. Moreover, 
an explicit policy language helps avoid 
simple mistakes. 

Bro consists of several layers. At the bot¬ 
tom, the network layer feeds a packet 
stream to the libpcap library (tcpdump 
uses this library). After some initial filter¬ 
ing, packets arrive at the event engine, 
which is con¬ 
trolled by the 
policy script 
interpreter. The 
event engine fil¬ 
ters out unwant¬ 
ed traffic. For 
Vern Paxson accepts Best instanC e )y0 u 

Paper Award from Program may care Qn j y 
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portmapper packets. Finally, the inter¬ 
preter makes intrusion announcements 
in realtime. A figure in the paper better 
describes the interface between each 
layer. 

Key to the design of Bro is a policy lan¬ 
guage. This strongly typed language aims 
to catch policy errors at compile time. 
One notable feature protects against 
malicious strings. Rather than terminat¬ 
ing a string with a NUL character, Bro 
represents a string by a vector of bytes 
and a byte count. If Bro were to use 
NUL-terminated strings, an intruder 
could trick a monitor with a string such 
as USER nice\OUSER root. No explicit 
looping mechanism (besides recursive 
calls) exists because Bro cannot afford the 
execution time, and loops open up denial 
of service attacks. The single-threaded 
implementation offers timer manage¬ 
ment (10,000 easily), interpretation 
instead of compilation, checkpointing, 
and the ability for offline analysis. The 
paper gives an overview of the language 
and offers several policy code snippets. 

The mere existence of a monitor invites 
attacks. Bro defends itself against three 
categories of attacks. An overload attack 
forces the monitor to drop packets so 
that an intruder can sneak in unnoticed. 
Bro defends against this attack by doubt¬ 
ing the monitors capabilities; the moni¬ 
tor will shed load if necessary. A second 
attack causes the monitor to crash. An 
intruder could cause fatal errors by 
exploiting bugs or making the monitor 
run out of resources. In defense, a moni¬ 
tor uses a watchdog timer and records a 
traffic audit trail. Vern notes that crashes 
are hard to prevent because a single bug 
in any program can open up attack 
avenues. A third attack involves sub¬ 
terfuge. A nasty intruder could mislead 
the monitor. For example, an intruder 
may fragment IP datagrams in hopes that 
the monitor will fail to reassemble the 
fragments. The paper devotes an entire 
page to this difficult problem. Vern also 
explained that security through obscurity 


alone is not sufficient, but you should not 
advertise a policy script because doing so 
could reveal local bottlenecks to an 
intruder. 

Wrapping up his talk, Vern gave the cur¬ 
rent status of Bro. Currently, Bro can 
analyze four specific applications: finger, 
ftp, portmapper, and Telnet. As for per¬ 
formance, Bro easily handles a 25Mbps 
FDDI ring during busy hours (the statis¬ 
tic in the paper is incorrect; the paper 
claims 50Mbps). Generally, the system 
drops no packets. However, the event 
engine processes about 200 packets/sec¬ 
ond after the filter discards unwanted 
packets. At LBNL, the monitor generates 
about 40MB of connection logs and 20 
realtime notifications each day. This 
resulted in several CERT reports and 
many account deactivations. The source 
is available upon request. See 
<http://www-nrg.ee.lbl.gov/nrg-papers.html> for 
more information. 

A participant asked whether Bro could 
handle the capacity of ATM and switched 
technology. Vern answered that, in such a 
case, you can deploy multiple coordinat¬ 
ed boxes. He does not expect any prob¬ 
lems arising from ATM packet assembly. 
Another audience member asked whether 
Bro would overload if placed on a gate¬ 
way. Vern explained that such a system 
could be a reactive firewall or could talk 
to a firewall or router. You want to filter 
out the majority of traffic. 


Cryptographic Support for Secure Logs 
on Untrusted Machines 

Bruce Schneier and John Kelsey, 
Counterpane Systems 



Bruce Schneier, president of Counterpane 
Systems, presented a paper on secure 

logs. Essentially, 
the secure log¬ 
ging system 
detects modifi¬ 


cations to logs 
on an untrusted 


machine. 


Bruce Schneier 


Drawing analogies to the legal system, 
Schneier explained that “we don’t prevent 
crime in this country; we detect it.” The 
same idea is put forth in secure logging. 
Schneier’s work includes the authorship 
of “Applied Cryptography” and creation 
of the Blowfish cipher. Instead of pre¬ 
senting slides in ascending order, he 
counted downward because he claims the 
audience “really wants to know when 
they can get out.” Incidentally, I saw 
Schneier writing his slides during the 
previous session. In any case, his talk 
went well, and he made the audience roll 
with laughter. 

In the general model, an untrusted 
machine, U, talks to a trusted machine, T. 
An ATM machine or smart card qualifies 
as an untrusted machine. U maintains 
audit logs, occasionally commits logs to 
T, but is not necessarily expected to be 
compromised. If an intruder attacks U at 
time t, the intruder cannot undetectably 
alter log entries before time t. 

There are limits to possible solutions. 
First, no security measure can protect U 
after time t. An intruder can do anything 
after time t. Second, if T and U commu¬ 
nicate online continuously, the problem 
no longer exists. Third, cryptography 
alone cannot prevent deletion. Write-only 
hardware, such printouts, or WORM 
drives can prevent deletion. 

Schneier identified a few wrong ways to 
protect logs. The logger could encrypt log 
entries, but then the key is stored on U 
(ignoring performance-heavy public key 
crypto). MACs (Message Authentication 
Codes) suffer from the same problem. A 
logger could use hash chains, but an 
intruder can fake them. 

The approach in this paper combines 
MACs and encryption keys for an irre¬ 
versible process. A complicated diagram 
depicts the addition of entries to a log 
file. Several variants of the logger exist 
(offline versions, phone transmission 
medium). See the paper for an outline of 
the protocol. 
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An audience member questioned whether 
this system can detect intrusions at the 
time of attack. Schneier explained that 
the secure logger does not exactly detect 
attacks; that’s a “hardware problem.” If an 
intruder can get into a system without 
generating log entries, then this system 
cannot help. Another participant pointed 
out that an electronic wallet can be 
attacked at time t=0. In Schneier’s 
scheme, he assumes the owner is an 
attacker. It is a vulnerability. Questioned 
about the difference between irreversible 
hashing and hash chains, Schneier 
responded that an attack could delete log 
entries in reversible hash chains. Chains 
allow easy forward hashing. Schneier’s 
logger uses hash chains, but prepends 
extra information. Finally, an audience 
member asked why the system does not 
use public-key encryption. If you have 
small logs infrequently accessed, would 
not PK encryption help? Schneier replied 
that PK encryption is too slow and 
annoying for the goals of this secure 
logger. 

In the future, Schneier hopes to provide 
better multiparty logging, distributed 
trust, and anonymization. His talk 
explained the problem of secure logging 
well, but the logger itself could not be 
fully explained in 25 minutes. Schneier 
has online information at 
<http://www.counterpane.com/secure-logs.html>. 

StackGuard: Automatic Adaptive 
Detection and Prevention of Buffer- 
Overflow Attacks 

Crispan Cowan, Calton Pu, Dave 
Maier, Jonathan Walpole, Peat Bakke, 
Steve Beattie, Aaron Grier, Perry 
Wagle, and Qiang Zhang, Oregon 
Graduate Institute of Science & 
Technology; Heather Hinton, Ryerson 
Polytechnic University. 

Leader of the IMMUNIX system surviv¬ 
ability group and one of the few tie-wear¬ 
ing USENIX attendees, Crispan Cowan 
talked about a general method to prevent 
buffer-overflow attacks. System adminis¬ 


trators typically 
patch vulnerable 
programs one at 
a time. Taking a 
proactive 
approach, 
StackGuard 
modifies the 
compilation process to prevent most 
overflow attacks. 

A buffer overflow can allow local 
accounts (or compromised accounts) to 
obtain root privileges. In the standard 
buffer-overflow attack, kids use cookbook 
methods to feed a long string into a func¬ 
tion that does not check array bounds. In 
doing so, an attacker can inject code into 
the stack, overwriting the return address. 
When the function returns, the system 
jumps to the memory location of choice, 
typically code to obtain a root shell. 

StackGuard uses a compilation technique 
to prevent overflows. The method is so 
simple you will cry: detect changes to the 
return address by pushing one more 
word on the stack. StackGuard pushes a 
“canary” value (a direct descendant of the 
Welsh miner’s canary) after the return 
address. When returning, a function 
checks whether the canary value has 
changed. The canary must be secret, ran¬ 
domly generated at execution time, and 
decidable. The last two conditions sound 
contradictory to me, but I haven’t looked 
under the hood. 

MemGuard, a variant of StackGuard, has 
granularity to protect a single word in 
memory. Unfortunately, MemGuard has 
disappointing results. Cowan admitted 
that the “5,400% to 8,800% overhead 
probably is not worth it.” But StackGuard 
requires a simple patch to GCC, which 
emits a little more in the function prolog 
and epilog. StackGuard function calls are 
more expensive, but GCC compilation 
time does not appear affected by 
StackGuard. GCC does not spend much 
time on function calls. 

Experimental evaluation shows that 
StackGuard defends against future 


attacks. Cowan’s group tried exploits 
from bugtraq, Linux security announce¬ 
ments, and <comp.unix.security>. In most 
cases, StackGuard detects an overflow, 
halts, then warns the user. For instance, 
the Samba overflow came out after the 
implementation of StackGuard, yet 
StackGuard detected the attack. However, 
StackGuard fails to detect attacks where 
the return address is not attacked. For 
instance, the SuperProbe overflow 
involves the rewrite of a function pointer. 
Cowan gave wonderfully simple demon¬ 
stration of StackGuard. Typing just a few 
commands, an unaltered dip binary pro¬ 
duced a root shell. When compiled with 
StackGuard, dip dumps core and warns 
of the overflow. 

Cowan identified two remaining prob¬ 
lems: restarting daemons and responding 
to an attack. Halting is not too important 
for daemons started by inetd. But persis¬ 
tent daemons such as sendmail or inetd 
need a restart mechanism. A watchdog 
program could restart such services. The 
second problem involves what to do after 
detecting an attack. A more restrictive 
program could be started (e.g., using 
MemGuard). This could result in denial 
of service. StackGuard is not perfect; 
buffer-overflow problems can get 
through. But StackGuard is effective 
against overflows you do not know 
about. This gives you time to apply 
patches, which you should still patch 
anyway. 

An audience member asked whether an 
attacker could guess every canary. Cowan 
explained that two versions of the 
pseudorandom number generator exist. 
One uses seeding from the time-of-day 
(cringe!) and another uses /dev/random. 
Luckily, StackGuard will not give an 
attacker a chance to guess a canary twice. 
Given that the canary is a 32-bit word, 
attackers will have to try to get around 
the canary rather than attack it directly. 

Overflow attacks usually overwrite data 
pushed earlier on the stack. To protect 
against a downward attack, return 
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addresses should live on another stack. It 
may be useful to put return addresses on 
another stack, but Cowans group did not 
do this. 

Another audience member asked why 
detect overflows instead of preventing 
overflows in the first place. Cowan 
replied that you would have to check on 
every write. You could check array 
bounds for every write, but StackGuard 
checks just once per function call. You 
may find lower overhead if reads occur 
more often than writes. 

I note that buffer-overflow attacks appear 
benign at first. But when combined with 
local account compromises, a single 
buffer-overflow (hundreds are known to 
exist) can turn your system to swiss 
cheese. The common attack works as fol¬ 
lows: an intruder will sniff a password 
(we all use encrypted Telnet, right?), 
exploit a cookbook overflow, install a 
packet sniffer, then repeat the first step. 

Related work includes Snarskii s FreeBSD 
libc fix and Solar Designer’s nonexe¬ 
cutable stack. Cowan notes that 
StackGuard and other solutions can com¬ 
bine for better protection. In the future, 
StackGuard hopes to protect nonstack 
data structures, integrate with intrusion 
detection software, and secure a Linux 
distribution. StackGuard is GPL’ed and 
currently works on the x86 architecture. 

A whole range of IMMUNIX projects can 
be found at 

<http://www.cse.ogi.edu/DISC/projects/immunix/>. 

Data Mining Approaches for Intrusion 
Detection 

Wenke Lee and Salvatore J. Stolfo, 
Columbia University 

Wenke Lee, a PhD student of Professor 
Stolfo, presented the paper on detecting 
intrusions by data mining. When one 
applies data mining to intrusion detec¬ 
tion, a systematic framework allows the 
construction of adaptive detection mod¬ 
els. Unfortunately, it was difficult to hear 


Lee, but his paper 
explains most 
topics in the talk. 

Lee aims to avoid 
manual or ad hoc 
intrusion detec¬ 
tion mechanisms. 
Such mechanisms 
fall into two categories: misuse detection 
and anomaly detection. The problem 
with misuse detection is that someone 
must manually code known intrusion 
detection patterns. Moreover, new pat¬ 
terns are not detectable. In anomaly 
detection, someone must select the right 
set of system features for measurement. 
No solid guidelines exist, just experience 
and intuition. 

Why use data mining? Intrusions usually 
leave trails of audit data. For example, 
cellular phone and credit card companies 
use data mining approaches to detect 
fraud. In data mining, you select appro¬ 
priate features to audit. Lee chose data 
from sendmail function call traces and 
tcpdump output. The rest of the system 
consists of a low-level learning agent, 
base detection agent, and meta detection 
agent. An agent will extract connection- 
level features such as the number of 
connection attempts, the method of 
termination, etc. 

Experimental results show single-digit 
misclassification rates for local traffic, but 
misclassification rates as high as 22% for 
inter-LAN communication. However, the 
addition of temporal statistical features 
reduces misclassification. Specifically, 
small window sizes for longer sampling 
periods produce better classification. One 
problem involves the selection of an opti¬ 
mal window size. A classifier should learn 
trends and patterns. For instance, it 
should predict whether you will visit Web 
site C after visiting Web sites A and B. 

Lee is just in the beginning of the project 
and hopes to ensure further work in data 
mining approaches to intrusion detec¬ 


tion. Currently, he is testing the effective¬ 
ness against known intrusions. 

After the session, Vern Paxson and Lee 
discussed ideas as USENIX attendees 
flocked around them like ants. Maybe we 
will see a hybrid of data mining and net¬ 
work monitoring in the future. You can 
find more information at 
<http://www.cs.columbia.edu/~sal/hpapers/USENIX/ 
usenix.html>. 

Session: Network Security 

Summaries by Gus Shaffer 

Each of these three presenters introduced 
an unanswered issue in network security 
protocols and presented a full implemen¬ 
tation of a solution. 

Securing ‘Classical IP Over ATM 
Networks’ 

Carsten Benecke and Uwe Ellermann, 
Universitat Hamburg 

With the increasing trend toward ATM 
networks and the desire for IP-based ser¬ 
vices on these networks, many new secu¬ 
rity issues have arisen. New services such 
as ATM ARP (ATM Address Resolution 
Protocol), have been required. One solu¬ 
tion that many try is the use of a tried- 
and-true IP security device, the firewall. 
But if used only in conventional ways, the 
firewall can have certain disadvantages in 
ATM networks. If placed between switch¬ 
es, it gives good security, but does not 
allow “native ATM” services between sub¬ 
nets. If coupled with one switch, “native 
ATM” services are available, but main¬ 
taining security requires a much deeper 
integration of firewall and switching ser¬ 
vices. This paper discusses the risks and 
possible solutions for this approach, 
including the following: 

1. A more secure 
ATMARP ser¬ 
vice. One sug¬ 
gestion for 
securing the 
services is in 

Carsten Benecke 
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the configuration of the ATMARP 
server. It is preferable to install an 
ATMARP server on a host in each LIP 
(logical IP subnet), as opposed to on 
the switch, for multiple reasons. One 
can control access to the host much 
more easily than to the switch. The 
security features of a host-based server 
can be easily increased with software, 
whereas one must rely on firmware on 
a switch. Giving each LIP its own 
ATMARP server lets it restrict access 
according to its own private security 
policy. 

2. Integration of the switch into a firewall 
concept. By generating a direct ATM 
connection, an external host may total¬ 
ly circumvent a firewall. The authors 
suggest using access control lists to pre¬ 
vent unwanted connections from exter¬ 
nal hosts using this technique. 

Benecke and Ellermann discussed more 
weaknesses and other possible solutions. 
They also pointed out that address filter¬ 
ing in the switch is not enough to enforce 
typical security policies and that they 
should be used in combination with fire¬ 
walls. You can find more information at: 
<http://www.cert.dfn.de/fwl>. 

A Java Beans Component Architecture 
for Cryptographic Protocols 

Pekka Nikander and Arto Karila, 
Helsinki University of Technology 

Nikander and Karila presented a new 
practical architecture and an implemen¬ 
tation framework based on the Beans 
architecture and security API of JDK 1.1 
and the Conduits* protocol framework 
for implementing application-specific 
protocols with relative ease. These sys¬ 
tems can be securely executed in a “pro¬ 
tocol sandbox” 
and can be 
securely down¬ 
loaded over the 
Internet and 
used without 
any prior 


arrangements of software installations. 
This new Bean-based system allows you 
to combine many small atomic units to 
create sophisticated protocols, making 
switches between encryption or authenti¬ 
cation methods relatively easy. The 
authors hope to extend the Java Beans 
support so that a graphical Beans editor 
could be used to compose protocols. The 
current implementation is the third in a 
series, a Java Bean-enabled version of the 
second prototype, which was a total 
rewrite of the first. It consists of 43 pub¬ 
lic classes, about 3,800 lines of Java 
source code, 3,040 lines of which were 
generated using a UML-based tool. You 
can find more information at: 
<http://www.tcm.hut.fi/~pnr/jacob/>. 

Secure Videoconferencing 

Peter Honeyman, Andy Adamson, 
Kevin Coffman, Janani Janakiraman, 
Rob Jerdonek, and Jim Rees, Center 
for Information Technology 
Integration, University of Michigan, 
Ann Arbor _ 

Researchers at CITI have worked to 
develop a secure videoconferencing sys¬ 
tem that is not only strongly encrypted 
and fast enough to give full motion 
video, but does all this in a provably 
secure way. In order to achieve this goal, 
they used VRA, a stream cipher invented 
by Bellcore cryptographers (Venkatesan, 
Rajagopalan, and Aiello). To store and 
distribute keys securely, they used the 
Shoup-Rubin key distribution protocol, 
which is a smart card-based key distribu¬ 
tion protocol between two communicat¬ 
ing parties and a trusted third party. 
Shoup-Rubin was proved not to disclose 
session keys, even to an extremely power¬ 
ful adversary, by its creators using Bellare 
and Rogaway s complexity theory tech¬ 
niques. The encryption and key exchange 
algorithms were then added to VIC, a 
freely available MBONE videoconferenc¬ 
ing tool, using GSS (Generic Security 
Service) API. 



Pekka Nikander 


All of this was 
achieved on 
commodity 
hardware, 

Pentium 166s 
running 
Windows 95, 
where the bottle¬ 
necks turned out to be MPEG video 
encoding and decoding, and Wintel data 
movement; the encryption made no dif¬ 
ference in throughput. But in measure¬ 
ments of time spent in encryption, the 
VRA more that doubled RC4s through¬ 
put. In the future, CITI hopes to add 
encrypted audio to VIC and possibly add 
a key revocation mechanism to Shoup- 
Rubin. You can find more information at: 
<http://www.citi.umich.edu>. 



Session: Distributed Systems 
Summaries by Jim Simpson 

Hillary Orman of DARPA/ITO chaired 
this session concerning the implementa¬ 
tion of security policies in various parts 
of a system, involving the interaction of 
various software agents. The first paper 
discussed a proposed solution to the 
inherent problem with security policies 
in distributed systems caused by hetero¬ 
geneous subsystems that have little or no 
knowledge about each other. The second 
involved an operating system security 
model used to control programs such as 
downloaded executables. It compares this 
model with language-based security 
models. The last paper in this session dis¬ 
cussed methods to alleviate loopholes in 
the current implementation of Java. 


Unified Support of Heterogeneous 
Security Policies in Distributed Systems 

Naftaly H. Minsky and Victoria 
Ungureanu, Rutgers University 

The general idea behind this talk con¬ 
cerned the fact that modern distributed 
systems are made up of many different 
subsystems which may have been 
designed separately, without knowledge 
of each other. They also might be 


May 1998 ;Iogin: 


11 


CONFERENCE REPORTS 




Naftaly H. Minsky 


governed by dif¬ 
ferent security 
policies. This 
may cause a 
problem when 
a single software 
agent within 
the system finds 


that it must interact or that it belongs to 
many of these subsystems and must 
accordingly be subject to disparate 
policies. 


To remedy the potential problems of this 
situation, Minsky stated that their solu¬ 
tion proposes a security scheme under 
which policies are defined explicitly and 
are enforced by a unified mechanism. 
Each policy under this scheme specifies 
what it deals with and how it deals with 
it. It is currently implemented in an 
experimental toolkit called Moses, which 
supports a number of policies such as: 

■ discretionary models that use capabili¬ 
ties or ACLs 


■ mandatory latticed-based control 
models 

■ sophisticated models required for com¬ 
mercial and clinical applications 

The motivation for this unified mecha¬ 
nism is best illustrated with the attempt¬ 
ed implementation of two policies 
designed for commercial application in a 
distributed system: 

■ Chinese Wall Policy, which, imple¬ 
mented in MLS, does not lend itself to 
distributed systems because data may 
belong to different administrative 
domains. (ACL or capability-based 
scheme implementation does not work 
within distributed systems because it 
does not scale well.) 

■ Sealed-Bid Auction Policy, which does 
not lend itself to traditional security 
schemes. 


A new sort of security mechanism can 
implement both of these policies. This 
system views a security policy as made up 
of a triple that includes: 


■ the set of messages regulated by the 
policy 

■ a distributed group of agents that can 
send and receive these messages 

■ a set of rules governing the exchange of 
the messages between the agents 

To implement a policy, several controllers 
are set up that interpret the rules for the 
policy, which is stored on one or more 
servers, called a secretary. This server also 
controls the current control states of each 
distributed agent. When a process needs 
to do something in the system using a 
particular policy, it must first connect to 
the server that stores the policy and ask 
to be associated with some distributed 
agent. Once the process authenticates and 
the server okays the connection, the serv¬ 
er assigns the process to a controller and 
sends it the current control state and 
public key of the agent. There are several 
ways the process can authenticate: 

■ a simple password 

■ an X.509 certificate 

■ an SDSI certificate 

If a secretary or a controller fails, a repli¬ 
cate may serve in its place to prevent fail¬ 
ure. This system scales well because the 
policy is enforced locally by each agent, 
so the number of agents in the group has 
no direct effect on how they work with 
each other. This form of distributed trust 
has many benefits: 

■ The creation of policies is simplified 
and makes some nontraditional 
schemes possible. 

■ A single agent can work with many dif¬ 
ferent policies. 

■ Enforcing policies is more efficient. 

■ The system scales well. 

There were a few questions, most involv¬ 
ing how the different parts of the system 
worked, which are gone over in the paper. 
Minsky politely thanked each person ask¬ 
ing a question for the question, and then 
began his explanations. One of the more 


interesting answers, one that I often - 
surprisingly - heard, was in response to a 
question about how you guarantee the 
authenticating client goes through a con¬ 
troller to get to the server? The answer: 
there are no guarantees. 

Operating System Protection for Fine- 
Grained Programs 

Trent Jaeger, Jochen Liedtke, and 
Nayeem Islam, IBM T.J. Watson 
Research Center 

Jaeger explained that his talk would be 
about phase 1 of a project called the Lava 
Operating System. Lava has a small ker¬ 
nel, and the goal of the operating system 
is to build a fine-grained access control 
system into it. 

They first took a look at implementing 
fine-grained access control through a sys¬ 
tem of monitors that store permissions of 
their contents, implement transformation 
of those permissions, intercept IPCs that 
are sent for its content, determine the 
authorization requirements for the oper¬ 
ation in the I PC, and authorize the oper¬ 
ation using the content’s permission. 

This operating system has support mech¬ 
anisms for control, but because they 
didn’t want to deal with the complexities 
of language-based mechanisms, they used 
a hardware-based mechanism. They do 
mediation over IPCs, which allow the 
operating system control over the media¬ 
tion because it can intercept IPCs. 

Concepts that they are building on 
include: 

■ programs that want to perform actions 
upon objects 

■ permissions based on principals that 
allow opera¬ 
tions to be 
performed 

Say there is a 
requester that 
wants to use a 
component in 
an application. 
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The components are downloaded and 
authenticated, and the principals are 
assigned to the components. They are 
then loaded via some path, and these 
paths are intercepted by a monitor that 
controls access rights the process has. 
When a monitor intercepts an I PC and 
the operation authorization semantics 
have determined that an operation 
should be authorized, the monitor uses 
the permissions from process to do so. 
Authorization capabilities cannot be 
forged because monitors accept them 
only from process load servers or other 
trusted monitors. Monitors can be 
assigned to multiple processes. 

To put these monitors to use in imple¬ 
menting security policies, Lava utilizes 
IPC redirection. Any IPC to a process is 
always handled by the monitor to which 
that process is assigned. This aids in 
things like mandatory access policies and 
suspicious process isolation. Redirection 
is enforced by the kernel for security rea¬ 
sons. Monitors will drop any request that 
does not conform to the security policy; 
they also will not accept unauthenticated 
messages for processes they control, 
thus protecting the system from outside 
attacks. This architecture allows for the 
building of hierarchical domains of 
control. 

Jaeger then went into performance/ 
response times of various actions a moni¬ 
tor might take, such as intercepting IPCs 
and working with authorization mecha¬ 
nisms. These are detailed further in the 
paper; however, the conclusion is that the 
overhead might seem to be high, but fast 
IPC and efficient authorization mecha¬ 
nisms help bring the overhead down to a 
reasonable amount. There is not a whole 
lot of data right now, but the ideal is a 
12% overhead for 30,000 IPCs with a 
current measurement around 30-40%. 


Expanding and Extending the Security 
Features of Java 

Nimisha V. Mehta, The Open Group, 
and Karen R. Sollins, MIT Laboratory 
for Computer Science 

Mehta offered a quick change of pace by 
talking about the ubiquitous Java and 
how to expand its current sandbox. This 
included: 

■ simpler policy configuration 

■ more easily extensible access control 
structure 

■ extension of security checks to include 
all level of Java programs 

Several different methods were used in 
trying to achieve these goals. The first 
covered was the use of logging facilities to 
determine what an applet might be up to. 
This comes in handy when tracking data 
transfers when trying to keep data confi¬ 
dential. If an applet has access to confi¬ 
dential information, you might not want 
it to access the network. However, anoth¬ 
er applet that does have access to the net¬ 
work may be running on the system. You 
do not want the second applet to get data 
from the first and then connect to the 
network, so you log all transactions of 
each applet. 

Another method is the concept of file 
ownership; this divides the file system 
into applet domains. Each file written by 
an applet is then owned by that applet. If 
so configured, a file written by one applet 
may not be accessible to another applet. 

To implement their design, they overrode 
the Security Manager that comes with the 
current JDK. This Security Manager is 
queried whenever an applet needs access 
to a system resource. The new security 
manager implements the proposed log¬ 
ging system, so whenever an applet goes 
to read or write a file, an entry is created 
in a log. The applet then becomes the 
exclusive owner of that file; a file cannot 
be owned by multiple applets. The entry 
is removed only when the file no longer 
exists. 


Mehta then pre¬ 
sented a proto¬ 
type of 

the implement¬ 
ed Security 
Manager and 
went over a new 
variable called 
Applet.Category. This label can be set to 
“suspicious” when an applet accesses over 
a certain number of protected files. 
Applets with the “suspicious” label are 
then subject to different, stricter policies. 
Another variable, PublicDirs, when used 
in conjunction with Applet.Category, 
allows for control over reading files. 
Another Applet.Category label, 
Contaminated, is set when a file is 
opened for reading; Contaminated 
applets are not allowed to connect to the 
network. 

Security issues that arose in implementa¬ 
tion involved: 

■ Errors. When an error occurs, should it 
affect all applets, or only the problem¬ 
atic applet? It should affect only the 
one applet. If a problem affects all 
applets, it’s probably a system problem. 

■ CheckX Methods. These are provided 
to check access to a certain resource; 
some Web browsers give access to the 
Security Manager and allow applets to 
query what their permissions are. Their 
current implementation logs these 
queries as accesses, and this might 
cloud the future for more accesses if a 
policy to limit an applet to so many 
accesses is set. 

■ Identifying applets. They are currently 
identified by their DNS hostname. 
Because servers sometimes use multi¬ 
ple machines to offload work, the same 
applet may come from several different 
machines and thus not be able to 
access its files at a later point. 
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Finally, Mehta went over performance. 
Their results showed that their modified 
Security Manager takes 1.67 times that of 
the regular AppletViewer’s, but that per¬ 
formance can be improved with more 
work in providing native support and by 
using a Just-In-Time Compiler (JITC). 

Questions followed. Most seemed to be 
about further definition of terms. What is 
meant by an applet that is no longer 
allowed access to the network? It can no 
longer make any more connections. Does 
this not debilitate the applet if it’s got a 
socket connection? No. 

Session: World Wide Web 
Security 

Summaries by Jim Simpson 

Chaired by Diane Coe of Concept5 
Technologies, this session provided 
insight on many of the current security 
problems that plague the Web. Annette 
Krannig’s paper about PLASMA dis¬ 
cussed a security implementation that 
can specifically address different types of 
content with different security methods, 
as opposed to something like SSL, which 
does complete encryption of all content 
on a lower level. JavaScript and some of 
its flaws appeared in the second paper, 
where a few people from Bell Labs pro¬ 
posed some methods to circumvent these 
problems. Finally, three people from 
Stanford University presented a finite 
state analysis of SSL 3.0 using a program 
called Murph. 

Towards Web Security Using PLASMA 

Annette Krannig, Fraunhofer-lnstitute 
for Computer Graphics IGD 

Krannig s talk addressed the issue of a 
lack of security that takes into account 
the multimedia or structural elements of 
Web documents. This is where PLASMA 
comes into play. PLASMA is a PLAtform 
for Secure Multimedia Applications. 
Because multimedia and hypertext sys¬ 
tems are an upcoming platform in the 
transfer of information, their security is a 
top priority. PLASMA was designed to be 


functional in sit¬ 
uations other 
than the WWW, 
however. To 
demonstrate its 
functionality, 
the Web was 
chosen because 
it is indeed an information transfer sys¬ 
tem that encapsulates data. 

PLASMA is useful in that it can specify 
different cryptographical algorithms, 
depending on the data. If the content is 
something more complex than simple 
text, perhaps a faster crypto algorithm 
might be used, even though it may be less 
secure. The selection of these services is 
determined by the end-user because that 
is the only person who knows how 
important a given content may be. PLAS¬ 
MA offers the concept of high-level secu¬ 
rity, which previously has not really been 
looked upon. 

The architecture behind PLASMA con¬ 
sists of several different modules that 
work in conjunction with each other: 

■ filter - the most important module (It 
breaks the data down into its compo¬ 
nents and notes this in a Script. The 
Script is later used when encrypting 
these components.) 

■ three security services - nonrepudia¬ 
tion, confidentiality, and reliability 

When users go to access data, they are 
queried for a PIN. If it is correct, they are 
granted access to the data storage area. 
After this, the users and the participating 
parties must mutually authenticate with 
each other to gain certainty about identi¬ 
ties; this is done with the X.509 authenti¬ 
cation protocol. During authentication, 
security policies are also transmitted in 
order for a Coordinated Security Policy 
to be agreed upon so all participants can 
securely transfer their data. 

PLASMA on the Web uses a proxy archi¬ 
tecture. These PLASMA proxies perform 
cryptographic operations on the data; 
proxies must be used to ensure browser- 


independent transfer of data. These prox¬ 
ies look for different tokens denoting 
PLASMA services: 

■ Authentication allows PLASMA clients 
to authenticate with each other. 

■ The container denotes that the packet 
contains PLASMA data and should be 
decrypted. 

■ The final token is used when you wish 
to close the session. 

When a user requests data, PLASMA gets 
them, encrypts them based on the pre¬ 
specified policy, and then sends them out 
as data over HTTP. The proxy on the 
other end receives the data, decrypts 
them, and then displays them. When the 
session is done, a Final token is sent to 
the server to end it. 

Security of Web Browser Scripting 
Languages: Vulnerabilities, Attacks, and 
Remedies 

Vinod Anupam and Alain Mayer, Bell 
Laboratories, Lucent Technologies 

Mayer quickly went over what his talk 
was going to be like and in so doing 
explained he would be pointing out some 
problems with the current implementa¬ 
tions of scripting languages on the Web. 
There are many different kinds of attacks 
to be played using scripts; one gone over 
in this talk was the Bell Labs attack. 

Several clients out there have security 
issues; Netscape 2.x through 4.x and 
Microsoft's IE 3.x through 4.x. In addi¬ 
tion, Microsoft uses VBScript in conjunc¬ 
tion with ActiveX and JScript. These 
scripting languages are integrated with 
and embedded in HTML. Their problems 
stem from not having a decent security 
framework to start with. In analyzing the 
security imple¬ 
mentations of 
the various 
scripting lan¬ 
guages, they 
came across a 
serious flaw in 

Javascript that Alain Mayer 



Annette Krannig 



14 


Security Special Issue ;login: 



would allow browser windows to be 
tricked into trusting scripts from rogue 
sites. To work around these problems, 
they introduced the idea of a safe inter¬ 
preter called SecureJS that assures data 
security and user privacy. 

A safe interpreter must implement: 

■ Access control. This is implemented 
through a partitioning of namespaces, 
to which objects existing in a context 
are assigned. After partitioning name- 
spaces, you have to figure out how to 
specify the partitions for read objects 
and write objects. Finally, there has to 
be a mechanism where access to exter¬ 
nal interfaces can be specified so that 
the script can do something if it needs 
to with the network or files. 

■ Independence of contexts. Resources 
for different contexts must be kept dis¬ 
joint. 

■ Management of trust. This controls the 
trust among different contexts, in case 
they need to work with each other. 

The safe interpreter would prevent a Bell 
Labs attack; the Bell Labs attack required 
that the attacking script persist across 
multiple document fetches, access data 
from other loaded documents, and be 
able to transmit captured data to a 
desired location. With secure JS, though 
the rogue site might originally set up two 
contexts that can communicate with each 
other, the trust relationship would have 
been removed if one of the contexts 
closed down; the contexts would be pre¬ 
vented from communicating with each 
other. 

By using an object-instance hierarchy in 
an access control system, a certain frame¬ 
work with which security policies can be 
implemented is realized. However, had 
thought been given to the security design 
for these scripting languages, the ability 
to prevent flaws would have been greatly 
increased. 


Finite-State Analysis of SSL 3.0 

John C. Mitchell, Vitaly Shmatikov, 
and Ulrich Stern, Stanford University 

Shmatikov started his talk by going over a 
few things about finite-state analysis in 
general and about the tool they used, 
Murph. Murph is normally used in hard¬ 
ware verification and analysis. 

Murph takes a specification and checks it 
through by explicit state enumeration. If 
it can go through all the states, the model 
satisfies the specification. What can we 
learn from this finite-state analysis? 

First, this is fairly high-level analysis, so 
the attacks include pretty much every¬ 
thing but cryptography, which is a low- 
level property of the protocol. They 
assume perfect cryptography and that the 
only way an attacker is going to be able to 
decrypt something is to have the key. 
Murph is useful for finding authentica¬ 
tion bugs and attacks involving version 
rollback. 

The first thing they looked at was the SSL 
handshake. It establishes secret keys 
between a client and a server. Thus they 
mutually authenticate to each other. 

In order to do that, they must do the 
following: 

■ C (client) must include its identity in 
its Hello message to the server. 

■ S (server) must send its public key in a 
certificate signed by a public authority. 

■ C also must have the CA sign its verifi¬ 
cation key. 

■ C and S must re-exchange information 
after the crypto handshake is complete 
to make sure there was no attack on 
the plaintext Hello messages and verify 
all the following messages. 

■ Nonces must be added to protect 
against replay attacks. 

One of the features of the SSL 3.0 server 
and client is that they can talk to SSL 2.0 
clients and servers. They took the sim¬ 
plest version of the protocol and gave an 


attack found by 
Murph. They 
then added part 
of the protocol 
that prevents the 
attack and ran 
Murph again. 
They continued 
this until, optimally, there were no attacks 
found. After going through these require¬ 
ments, Murph found another attack 
involving the finish of the handshake that 
is easily prevented by assuming the pro¬ 
tocol is incomplete until final verification 
messages are sent. 

In the end, they learned that finite-state 
analysis can be applied to complex proto¬ 
cols like SSL and actually find new prob¬ 
lems with the protocol in given instances. 

There were a few questions. One person 
inquired why they used Murph instead of 
other modelling tools. It came down to 
unfamiliarity with how other tools might 
model SSL and their use of Murph in 
other cases. 

Session: Cryptography 
Summaries by Kevin Fu 

Certificate Revocation and Certificate 
Update 

Moni Naor and Kobbi Nissim, 
Weizmann Institute of Science 

Kobbi Nissim presented a paper on effi¬ 
cient certificate revocation, analyzing 
existing certificate revocation schemes 
and a new scheme with better incremen¬ 
tal efficiency. The Naor-Nissim (NN) cer¬ 
tificate revocation scheme uses Certificate 
Revocation Lists in the form of authenti¬ 
cated search structures. Nissim won the 
best student paper award. 

Certification involves three parties: a 
trusted certification authority (CA), an 
untrusted directory, and untrusted users. 
A CA issues and revokes certificates 
offline and periodically updates a directo¬ 
ry. Users query a directory for “proofs” of 
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validity and 
receive personal 
certificates from 
a CA. This paper 

F addresses the 

7 problem of 

. ^ revoking users’ 

Kobbi Nissim 

certificates while 

keeping communication costs and mes¬ 
sage sizes to a minimum. 


Nissim summarized three existing certifi¬ 
cate revocation schemes: Certificate 
Revocation Lists (CRLs), Micali’s 
Certificate Revocation System (CRS), and 
Kocher’s Certificate Revocation Trees 
(CRTs). The CRL offers the simplest 
approach. A CA periodically sends a digi¬ 
tally signed message to a directory. This 
message lists all revoked certificates. An 
obvious drawback is that the message can 
grow overwhelmingly large. In CRS, a CA 
periodically signs a message denoting the 
validity of each certificate (revoked or 
not revoked). CRS has excellent query 
communication costs but suffers from an 
increase in CA-to-directory communica¬ 
tion. CRTs use binary hash trees to 
authenticate statements about certificate 
validity. CRT has the advantage that the 
entire CRT is not necessary to verify a 
given certificate. Moreover, users can eas¬ 
ily prove certificate validity to other 
users. However, updates cause the recom¬ 
putation of the entire CRT. 


involves recomputing the path (of hash¬ 
es) from the root node to the leaf repre¬ 
senting the revoked certificate. This com¬ 
putation requires knowing all nodes on 
the path from the root to the leaf, along 
with all the children of the nodes on this 
path. Then to prove the validity of a cer¬ 
tificate, a user must demonstrate two 
paths from the root node to two neigh¬ 
boring leaves such that the serial number 
of the unrevoked certificate is sand¬ 
wiched between the values of the neigh¬ 
boring leaves. Because a proof of validity 
is small and hashes can be easily verified 
by any user, the new scheme allows users 
to efficiently prove validity to each other, 
reducing the user-to-directory communi¬ 
cation costs. 

Nissim exhibited a table that denotes the 
presence or absence of desirable qualities 
in CRLs, CRS, CRTs, and the NN certifi¬ 
cate. Unfortunately, the paper does not 
include the same table, but you can 
deduce the information by reading the 
itemized lists within the paper. Qualities 
include low CA-to-directory communica¬ 
tion, low directory-to-user communica¬ 
tion, high directory update rate, whether 
a user may hold a proof of validity, scala¬ 
bility, and the existence of an update 
mechanism. The NN scheme works well 
except that the amount of directory-to- 
user communication (and thus the over¬ 
all amount of communication) increases. 


In the NN certificate revocation scheme, 
authenticated directories allow efficient 
directory queries and certificate “proof” 
updates. NN actually consists of a family 
of solutions, but Nissim demonstrated 
the 2-3 tree version. Leaves represent 
revoked certificates’ serial numbers (in 
ascending order), and values of internal 
nodes result from collision-intractable 
hashes of their children. The paper 
describes other data structure variations. 

To vouch for the validity of the authenti¬ 
cated data structure, a CA signs a mes¬ 
sage containing the root node and tree 
height. Checking for a revoked certificate 


The new scheme can also update certifi¬ 
cates incrementally. In traditional certifi¬ 
cation schemes, CAs may issue short-life- 
time certificates, then reissue new certifi¬ 
cates for each user. But the CA becomes a 
bottleneck. In the NN scheme, Nissim 
suggests that the CA broadcast an update 
message to all users. Taking advantage of 
the tree structure, users can update their 
certificate “proofs” appropriately. An 
audience member asked what would hap¬ 
pen if a directory or user were to miss an 
update. Nissim replied that proxies can 
collect update messages. Furthermore, 
one can authenticate proxies by checking 


the time of an update because the reissu¬ 
ing period is a known expression. 

The appropriate revocation method 
depends on requirements of response¬ 
time (propagation of revocation) and 
efficiency (the amount of communica¬ 
tion). I recognize two main reasons for 
certificate revocation. Casual revocations 
result from noncritical reasons such as 
job changes or college graduation. If risk 
is low and most revocations are casual, 
decreasing the amount of communica¬ 
tion at the cost of more propagation 
delay may be acceptable. However, revo¬ 
cations due to a compromise need imme¬ 
diate revocation. In a high-risk system, 
immediate revocations may justify the 
cost of extra communication. 

Nissim’s clever overlays helped introduce 
certificate revocation, but too many com¬ 
plicated ideas uprooted the end of his 
talk. Nevertheless, the NN certificate 
revocation scheme is elegant and worthy 
of the best student paper award. 

Attack-Resistant Trust Metrics for Public 
Key Certification 

Raph Levien and Alexander Aiken, 
University of California, Berkeley 

Raph Levien, a graduate student of 
Alexander Aiken, presented a paper on 
the role of trust metrics for attack-resis¬ 
tant public key certification. The authors 
characterize existing trust metrics, estab¬ 
lish a theoretical best case in their model, 
and offer a metric that meets the theoret¬ 
ical best case. 

Trust metrics address the problem of 
binding public keys to opaque names. For 
instance, an email address may bind to a 
trusted public key. Trust metrics aim to 
accept most 
good bindings 
but reject forg¬ 
eries. By requir¬ 
ing multiple cer¬ 
tifications, bind¬ 
ings become 
more attack 
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resistant. In the general case, a certifica¬ 
tion authority asserts that a key k belongs 
to a name n. This model naturally leads 
to a certification graph where nodes are 
keys or name/key associations and edges 
represent certification. A trust 
metric evaluates such a graph and out¬ 
puts either accept (trusted) or reject 
(untrusted). 

Levien admitted that the following makes 
two bold assumptions: the metric will 
accept most of the good name/key bind¬ 
ings and the name space is opaque 
(names reveal no information). Without 
these assumptions, the analysis becomes 
intractable. He suggests that the metric is 
good for email but maybe not for high- 
security applications. 

The proposed model considers two types 
of attacks. In a node attack, an adversary 
steals keying material from a CA. The 
adversary could reuse the keying material 
over and over. In an edge attack, an 
adversary can convince a CA to falsely 
certify a node. The adversary does not 
actually have the keying material. Why 
distinguish between node and edge 
attacks? It is harder to protect against 
edge attacks. 

Within the paper you can find a table of 
successful attack thresholds. The table 
summarizes the necessary number of 
compromised nodes and edges to invali¬ 
date a trust metric. Resistance to attack 
ranged from single points of failure (just 
a single node) to quadratic numbers of 
nodes. 

The maxflow-edge metric achieves the 
theoretically best case. Each key is certi¬ 
fied by exactly d other keys (for concrete¬ 
ness, d could be 10). This method is con¬ 
sistent with both the Web-of-trust and 
the CA model. For a successful node 
attack, an adversary must compromise d 
nodes. Approximately d 2 nodes or edges 
are necessary for a successful edge attack. 
Other attacks include chosen node 
(breaking a certain key) and random 
node (breaking any key). Both attacks 


need d nodes for a successful node attack 
or about d 2 nodes for a successful edge 
attack. 

Levien mentioned problems with metric 
evaluation. Trust metrics are limited, cost 
grows slowly with cost of certification, 
will not scale up to the Internet. Levien 
calls the graph model somewhat simplis¬ 
tic. For instance, revocation is not part of 
the model. The paper could use more 
detailed captions so the casual reader can 
see the main ideas. Breaking what must 
be a USENIX record, Levien delivered his 
talk with several minutes to spare. This 
paper offers good advice for designers of 
authentication metrics. You can find the 
paper and related information at 
<http://www.cs.berkeley.edu/~raph/>. 

Software Generation of Practically 
Strong Random Numbers 

Peter Gutmann, University of 
Auckland 

Peter Gutmann reviewed poor pseudo¬ 
random number generator (PRNG) 
implementations and presented a practi¬ 
cally (not pseudo) strong random num¬ 
ber generator. Gutmann s accomplish¬ 
ments include the Secure File System and 
CryptLib. This self-proclaimed eternal 
graduate student warned the audience of 
his tendency to speak fast. In order to 
thwart this habit, an associate routinely 
shot him with a Texan rubberband gun 
(three times, to be exact). 

Gutmann first highlighted significant 
holes found in PRNG implementations, 
including Netscape, Kerberos V4, 
MIT_MAGIC_COOKIE, and SESAME. 
Because these implementations used pre¬ 
dictable and/or public seeding, one could 
easily determine the seed. Once an adver¬ 
sary has the seed, most PRNG implemen¬ 
tations become deterministic. In fact, 
Gutmann looked at the SSH source code 
just before giving his talk. Apparently the 
SSH generator does not use a one-way 
function (OWF); rather it uses a linear 
feedback shift register (LSFR) and expos¬ 


es the internal 
state of the pool. 

In designing a 
practically strong 
random number 
generator 
(PSRNG), 

Gutmann accu¬ 
mulated a list of general requirements. A 
PSRNG should protect against input 
analysis, manipulation of input, output 
analysis, and disclosure of internal state. 
Moreover, a PSRNG should use good cod¬ 
ing practices. For example, Gutmann 
complained of the difficultly in under¬ 
standing spaghetti source code in PGP 2.x. 

A PSRNG should tap several sources for 
randomness. Random sources include the 
purely physical devices (lava lamps, 
radioactive decay); physical and postpro¬ 
cessing (SGI00); multisource; single¬ 
source (PGP 2.x or /dev/random); secret 
nonce and PRNG (Applied 
Cryptography); fixed secret value and 
PRNG; or a known value plus a PRNG 
(Netscape, Kerberos V4, SESAME). 

To gauge the effectiveness of entropy 
polling, Gutmann tried to compress suc¬ 
cessive samples of random data. He ana¬ 
lyzed entropy polling on several plat¬ 
forms. DOS and OS/2 do not offer much 
entropy. In Windows 95 and Windows 
NT, you have some relatively nondeter- 
ministic system statistics to exploit. 
Surprisingly, Gutmann found that 
Win 16/32 produces lots of entropy upon 
reboot (about 2.5 times as much as a 
long-running machine). This results from 
the startup of 16-bit Windows drivers in 
somewhat nondeterministic order. 
However, network statistics in Windows 
NT contain almost no entropy, and 
reboots cause little change in entropy. In 
evaluating UNIX randomness polling, 
Gutmann had to “handwave.” BSD has 
more sources of randomness, but 
Gutmann did not test rebooted machines 
because 150 people use his only BSD 
machine. 
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Protecting the pool state is as important 
as protecting cryptographic keys. In 
UNIX, root can use the mlock () call. 

And in Windows NT, locking does not 
work as documented. Macs can use the 
HoldMemory () call. Windows 95 locking 
does not work (the function returns 
“true”). Because Windows has “methods” 
to read the pool, one can obfuscate things 
by spreading the pool all over the place. 
Gutmann found this method “pretty 
good” 

Gutmann also presented a PSRNG imple¬ 
mentation that is better described by dia¬ 
grams in the paper. In his PSRNG, he 
used hard-coded paths to utilities such as 
netstat to acquire randomness. He rec¬ 
ommends running the randomization 
process with the UID nobody (so as not 
to expose root-privileged information) 
and timing the harvest of random num¬ 
bers to kill slow entropy sources. 

CryptLib contains Gutmann’s practical 
random number generator. 

A participant questioned Gutmann about 
blocking issues in the Linux implementa¬ 
tion of /dev/random. If the /dev/ran 
dom is “drained” of its randomness, it 
may block to obtain more entropy. 
Gutmann explained that one cannot easi¬ 
ly speed up /dev/random because it tries 
to estimate how long to stir the pool for 
the amount of randomness you request. 

If you empty the pool, /dev/random will 
block until the pool is refreshed. Trading 
some security for performance, programs 
may find the urandom () call sufficient 
for some applications. 

Throughout the talk Gutmann gave ran¬ 
dom bits of advice. For instance, generat¬ 
ing a public and then the corresponding 
private key from the same pool can 
expose the state of the pool for the pri¬ 
vate key. You have to keep them separated 
or intruders will come out to play. 

Gutmann hesitated to call his scheme 
pseudorandom in the pure sense. 
Pseudorandomly generated numbers usu¬ 
ally refer to bit strings indistinguishable 


from truly random bit strings, given a 
polynomial amount of computation 
time. However, most PRNGs suffer from 
performance drawbacks. Instead, 
Gutmann calls his scheme practically 
random - a balance between trial-by-fire 
security and performance. 

I note that even the experts can overlook 
PRNG problems. For instance, Jeff 
Schiller, a well-established security 
expert, co-designed Kerberos and co¬ 
authored an Internet RFC titled 
“Randomness Recommendations for 
Security” in 1994 (see RFC 1750). 
However, people found a flaw in the 
Kerberos V4 random number generation 
in 1996! Even the experts can overlook 
random number generation. Therefore, 
PSRNG designers should pay careful 
attention. 

This entertaining talk addressed issues of 
practical security and good implementa¬ 
tion practices. For more information, see 
<http://www.cs.auckland.ac.nz/~pgut001/>. 

INVITED TALKS TRACK 

The Security Product Market: Trends 
and Influences 

Marcus J. Ranum, Network Flight 
Recorder Inc. 

Summary by Kevin Fu 

Clad in western-style boots and wearing 
just-out-of-bed hair, Marcus Ranum 
spoke about money and its effect on the 
security industry. Known for his work on 
firewalls, Ranum now serves as president 
and CEO of Network Flight Recorder Inc. 
and has been chief scientist at V-ONE 
Corporation. Ranum gives a disclaimer 
that his opinions could be right or 
wrong. Use his opinions at your own risk. 

One morning people just “woke up” as 
security experts. But apparently they 
never went back to sleep; Ranum calcu¬ 
lates that the US security market has a 
70% compound annual growth! Such 
enormous changes come from natural 
growth, IPOs, and the injection of VC 



Marcus J. Ranum 


money (or ener¬ 
gy, as he 
describes it). 
Several security 
companies 
announced IPOs 
between 1995 
and 1997. IPOs 
pressure companies into short-term 
development. Investors expect something 
each quarter. Investors salivate over 
Internet-related IPOs coincidentally 
scheduled with interviews, articles, and 
industry initiatives. However, IPOs and 
VC often produce artificial growth. 


As an aside, Ranum offered an exaggerat¬ 
ed get-rich-quick scheme: go to security 
companies and read the guest register. 
Maybe you will see the names of a lawyer, 
some investment bankers, and a promi¬ 
nent CEO all on the same day. Then bet 
with your kids' college tuition. I could 
almost hear the audience thinking aloud. 


With new capital, a company can either 
compete like mad or perish. It can outsell 
a competitor, claim to own most of the 
market share, buy the pieces it does not 
own, or watch its stock value sink. 
Investors don't care about technical 
details of security. They care about the 
right press. Of course, this produces lots 
of short-term fluff. Most public compa¬ 
nies just want to get something out the 
door because they cannot develop long¬ 
term strategies while pleasing investors 
each quarter. 


Ranum then gave his opinion on future 
industry trends. Instead of licensing tech¬ 
nology, companies will acquire or merge 
with others. For instance, Security 
Dynamics (authentication) purchased 
RSADSI (encryption). Likely merger 
paths include the marriage of authentica¬ 
tion and firewall technology. However, 
Ranum does not expect monster IPOs 
from encryption companies. And every¬ 
one knows the importance of controlling 
a public key infrastructure (PKI) - that’s 
the problem! Ranum vividly described 
wannabe CAs as “greedy pigs” who 
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“knocked over (the PKI) while charging 
the trough ” 

The next part of Ran urn’s talk concerned 
new growth areas. Intrusion detection 
will become popular. “Network grep” 
technology has a big market because it’s 
easy to explain. You passively look for 
intrusion patterns. (See the summary on 
“Bro.”) However, virtual private networks 
have their lines drawn; it’s too late for 
startups. 

By 2000, analysts expect a $14 billion/ 
year market for complete, managed net¬ 
work systems. Customers want one box 
(count ‘em, one) for security, firewalls, 
and pizza. The one-trick pony company 
will give way to one-stop shopping. As a 
side effect, bogus products and bogus 
consultants will proliferate, tarring the 
real security experts with bad press. 

Name recognition will become the metric 
of security quality. Customers will choose 
one of the five big-name companies. 
Expect serious commoditization. 

What is the effect on security? The indus¬ 
try gobbled up everyone who under¬ 
stands security. Moreover, security 
experts can charge top dollar - attracting 
wanna-bes and diluting the market. 
However, Ranum offers some assurance 
that the joyride will soon slow down; 
astronomical fees will not last forever. 

Throughout his talk, Ranum advised 
people to learn more about Windows NT. 
He explained that “Microsoft takes things 
the customer wants, then rolls it into an 
operating system.” People want to use NT 
because they wrongly believe it is easier 
than UNIX. The UNIX community can 
partially blame itself for this perception. 
We bicker over flavors of window man¬ 
agers and GUIs; we “scare people” into 
using NT. 

If you design a plugin security module 
for NT, you will get money. Microsoft 
will either buy you or steal you, but either 
way you will get a red Ferarri. Otherwise 
Microsoft will drive you to the ground. 
“You have to be a total schmuck to fail,” 


said Ranum. In the end, everyone will use 
NT. “Cry, but don’t laugh,” he warns. 

An audience member asked for justifica¬ 
tion that token-based authentication sys¬ 
tems and smart cards will soon fade away. 
Ranum replied, “Why carry a token when 
you can carry a Pilot?” He further 
explained that tokens alone do not com¬ 
plete transactions and that smart cards 
need backing from computer giants for 
widespread acceptance. 

I note that large growth reduces the accu¬ 
racy of market predictions. If the security 
market has a compound growth of 70% a 
year, no one can accurately predict the 
future. For more information about 
Ran urn’s work, see 
<http://www.clark.net/pub/mjr/>. 

Computer Security and Legal Liability 

Moderator: Steve Bellovin, AT&T Labs 
- Research 

Panelists: Tim Lagankamp, Interliant 
Corporation, John Courtney, Andrews 
& Kurth, LLP, and Peter D. Kennedy, 
George Donaldson & Ford, LLP 

Summary by Gus Shaffer 

Tim Lagankamp opened the session with 
a presentation on the liability of a system 
administrator in a break-in situation. The 
primary issue in this case is obvious, and 
not-so-obvious, neglect of duties. What 
exactly is your obligation to your cus¬ 
tomer’s security, what could/should you 
have done to ensure that security, and is 
your lack of action clearly a direct cause 
of the opening? 

John Courtney followed Lagankamp with 
an overview of the liability of a vendor 
whose product allows a break-in. The 



vendor’s legal status in this situation 
is similar to that of the sysadmin. Did 
they knowingly leave security holes, and 
exactly how secure must they make their 
software in a buyer-beware market? 

Peter Kennedy finished off the initial pre¬ 
sentations with a look at hacker liability 
and the legal pursuit of a hacker from the 
victim’s point of view. Issues included 
financial obligations of hackers for dam¬ 
age due to their intrusion and pursuit of 
hackers through international borders 
and over a chain of accounts. 



The question-and-answer session also 
touched on topics such as software licens¬ 
ing and the legal aspects of e-commerce. 


Factoring: Facts and Fables 

Arjen K. Lenstra, Citibank, N.A. 

Summary by Kevin Fu 

This talk offered a historical perspective 
of factoring and security assumptions. 
The world’s foremost expert on factoriza¬ 
tion, Arjen Lenstra became widely known 
when his team cracked the RSA-129 chal¬ 
lenge at Bellcore. Lenstra currently works 
for Citibank and has fun as president of 
Digicrime. He emphasized that this talk 
has no relation whatsoever to his employ¬ 
er. He also noted that this is his first time 
at a USENIX Security Symposium and 
that “you can’t expect much else from a 
banker.” 

Factoring is a simple problem: given an 
odd nonprime n, find a nontrivial factor 
of n. The problem of testing primality is 
easy. In theory, this runs in random poly¬ 
nomial time while in practice, it runs in 
deterministic polynomial time. However, 
people believe that factoring large num¬ 
bers (with no small factors) is difficult. 
This is a religion, and there is no evi¬ 
dence to show it is true. Everyone seems 
to agree, but, says Lenstra, “I have no idea 
why.” 

According to the recently deceased James 
Ellis (<http://www.cesg.gov.uk/ellisint.htm>), 
the British government had trouble 
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maintaining lots 
of keys for the 
armed forces. 

Therefore, they 
sought a system 
that required no 
prior key. This 
account of Non- 
Secret Encryption (NSE) exists in a 1970 
CESG report by J. H. Ellis: “The 
Possibility of Secure Non-Secret Digital 
Encryption.” Then in November of 1973, 
C. C. Cocks wrote “A Note on Non-Secret 
Encryption” in a CESG report. The algo¬ 
rithm proposed by Cocks (CCC) looks 
very similar to RSA. Interestingly enough, 
CCC did not consider signature use. Of 
course, Diffie-Hellman appeared in 1976, 
and RSA appeared in 1977. Another 
scheme from CESG is based on DLP in a 
ring rather than a multiplicative finite 
field. This report was made months 
before Diffie-Hellman. Lenstra asked,: 
“Were PKCS, RSA, and DH first discov¬ 
ered in the UK?” For a dramatic effect, he 
left the rest of the slide empty. 

Security of “accepted” PKCS is based on 
the supposed difficulty of factoring or 
taking discrete logs. Do we have nontriv¬ 
ial lower bounds for difficulty of factor¬ 
ing or DLP? No, except for some special 
cases of no practical use. There do exist 
nonpolynomial upper bounds from algo¬ 
rithms such as the Quadratic Sieve (QS) 
in 1982 and the Number Field Sieve 
(NFS) in 1989. Conclusion: perceived 
security of PKCS is based on “our 
credulity and mathematical incompe¬ 
tence.” 

Lenstra explained that plenty of people 
who have never factored are talking 
about factoring. For instance, Richard K. 
Guy doubts “anyone can factor 80 digits 
without special form in the present cen¬ 
tury” in his 1976 paper, “How to Factor a 
Number.” Martin Gardner wrote of “A 
new kind of cipher that would take mil¬ 
lions of years to break.” In Lenstra s opin¬ 
ion, a laptop computer will soon be able 


to factor an 80-digit number in a single 
day. 

To argue his point, Lenstra extrapolated 
current factoring capabilities. In 1994, a 
QS factored an RSA-129 modulus. This 
required 5,000 MIPS years for stage 1 
(sieving) and two days on a 16K MasPar 
for stage 2 (matrix). Then in 1996, an 
NFS factored a 130-digit number in less 
than 700 MIPS years for stage 1 (68 
hours and 700MB). However, stage 2 
required much more computation time, 
even on a Cray C-90. Extrapolating these 
figures, Lenstra believes factoring a 512- 
bit number with a QS would require 
500,000 MIPS years for sieving and four 
days (and 1GB of space) on a Cray C-90 
for the matrix. Substituting NFS, sieving 
would take 20,000 MIPS years, and 
matrix computations would take three 
months (and 4GB of space). Therefore, 
512-bit moduli are not long enough for 
current technology. But factoring 1,024- 
bit moduli seems hopeless. Just to sieve, 
the QS would require 10 15 MIPS years, 
and the NFS would take 10" MIPS years. 
Lenstra concludes that 512-bit QS factor¬ 
ization is feasible, 512-bit NFS factoriza¬ 
tion is hardly feasible, and 1,024-bit fac¬ 
torization is hopeless. 

Looking to the future, Lenstra addressed 
how faster processors and new theory 
affect factoring. Speeding up a processor 
will not significantly improve current 
sieving techniques. Unless memory 
speeds increase, faster processors will not 
help. As for new theoretical insights, 
Lenstra says, “Anything may happen.” 

Does difficulty imply security? It does if 
the entire production process is closely 
watched by people who understand all 
issues involved. But many people are 
either “laid off or promoted to security 
jobs.” Then how can you avoid “creative” 
products? You could use trusted software 
(but does it exist?). Reading and under¬ 
standing lots of source code is impracti¬ 
cal. Trusting employees to write your 
own code is unrealistic. You could select 


the right vendor, but how? Combining 
products from different vendors is expen¬ 
sive, slow, and may not work. These 
problems apply to everything (operating 
systems, compilers, etc). Some experts say 
160-bit elliptic curve cryptosystems 
(ECC) offer security comparable to 
1,024-bit RSA. Lenstra believes 160-bit 
ECC is merely very difficult, not impossi¬ 
ble. (See the next talk.) 

Lenstra summarized that proving the dif¬ 
ficulty of IFP or DLP would not change 
anything because hardness of IFP or DLP 
does not imply hardness of many algo¬ 
rithms such as RSA. However, fast algo¬ 
rithms to solve IFP and DLP would top¬ 
ple most of the foundations of modern 
public key cryptography. Lenstra con¬ 
cluded by asking, “Why won’t business 
people leave the Internet alone?!” 

An audience member asked what to do if 
you were to find a fast factoring algo¬ 
rithm. Lenstra offered two suggestions. 
First, the discoverer should make the 
finding extremely public and publish the 
work as soon as possible - in order to 
save his or her own skin. As an alterna¬ 
tive, Lenstra told the audience, “Just tell 
me about it.” Some confusion erupted 
over key sizes. Do not confuse bits with 
digits. For instance, RSA-129 (digits) = 
429 bits. 

Elliptic Curves - Ready for Prime Time 

Alfred Menezes, University of 
Waterloo 

Summary by Kevin Fu 

In this invited talk, Alfred Menezes gave a 
quick introduction to elliptic curve cryp¬ 
tosystems and their advantages over other 
cryptosystems. Menezes charged into the 
most mathemat¬ 
ical talk of the 
symposium. His 
work includes 
co-authorship of 
the Handbook of 
Applied 
Cryptography 
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and Elliptic Curve Public Key 
Cryptosystems. Once at Auburn 
University, he now works for the 
Advanced Cryptographic Research 
Center at the University of Waterloo. 

Menezes began by defining multiplicative 
groups in a finite field. For instance, dis¬ 
crete log problem (DLP) cryptosystems 
usually operate in Z^. 

represents a multiplicative group 
modulo an integer p. This is a set consist¬ 
ing of the positive integers less than or 
equal to p that are relatively prime to p. 
When p is a prime, the set consists of 
{1,2,..., p-1} and having a cardinality 
of p- 1. For instance Z] 3 = [ 1, 2, 3, 4, 5, 6, 
7, 8, 9, 10, 11, 12}. 

Why use fancy groups other than just Z*? 
Arithmetic and security of protocols may 
be more efficient or better. For instance, 
you could use smaller numbers, yet retain 
the same security. 

Elliptic curve cryptosystems (ECC) are 
based on two variations of the DLR An 
elliptic curve comes from the equation 
y 2 = x 3 + ax + b where a and b are ele¬ 
ments of Z* such that 4a 3 + 27b 2 does 
not equal zero (mod p). The set E(Z^) 
consists of all points (x,y), in Z' p , that sat¬ 
isfy the above equations, together with a 
special “point of infinity.” Given a fixed 
prime p, there are many curves to choose. 
This means everyone could share the 
same prime, allowing construction of 
cheap, special-purpose hardware. Because 
ECC appears to provide good security 
with small secrets and little energy, com¬ 
panies like Motorola will want to use 
ECC in small devices such as pagers. 

Menezes took a defensive stance on ECC. 
Has 1FP been intensely studied? Yes, but 
Gauss could not even perform modular 
exponentiation. This prevented him from 
further success. Moreover, the Number 
Field Sieve (NFS) would have been use¬ 
less to them because computers did not 
exist. The Integer Factorization Problem 
(IFP) was really studied in the last 20 
years. IFP is “sexier” than DLP, but in 


Menezes s opinion, IFP is not a better 
basis than DLP. None of these systems is 
provably secure; each makes heavy-duty 
assumptions. ECC assumes an elliptic 
curve analog of DLP. There exist good 
breaks on specific instances of ECC, but 
no subexponential algorithm has been 
found for the general case. 

Although ECDLP was just proposed in 
1985, DLP and ECDLP abstractly con¬ 
cern the same problem - just different 
arithmetic structures. Many DLP prob¬ 
lems apply to ECs. Therefore, elliptic 
curves have been studied about as much 
as DLP. IFP attacks appear to have better 
software attacks. For instance, the RSA- 
129 effort involved several hosts over the 
Internet. However, DLP-based cryptosys¬ 
tems have better hardware attacks 
(according to Wiener). 

An audience member asked about patent 
issues with ECC. With RSA, patent issues 
come into play. But for general ECC, no 
patents exist (just certain implementa¬ 
tions). With ECC, you can avoid patents. 
However, government standards protect 
liability. Some companies like patented 
technology for liability and licensing rea¬ 
sons. 

Currently, no subexponential attacks on 
ECC exists. However, cryptographers dis¬ 
agree on whether to assume no subexpo¬ 
nential attacks exist simply because no 
one has found one. Many cryptographers 
find the security comparisons between 
ECC and DLP hard to justify. 

Because describing Menezes s diagrams in 
words hardly does justice, I suggest read¬ 
ing his book, Elliptic Curve Public Key 
Cryptosystems , or the paper, “Elliptic 
Curve DSA (ECDSA): An Enhanced 
DSA.” 

See <http://www.dms.auburn.edu/~menezal/> for 
more information. 


Securing Electronic Commerce: Applied 
Computer Security or Just Common Sense 

Clifford Neuman, University of 
Southern California _ 

Summary by Dug Song 

Neuman’s talk focused on the particular 
security requirements of electronic com¬ 
merce, which need to take into considera¬ 
tion unique business needs (such as 
authorization of payment, controlled 
access to internal systems by customers, 
etc.). These include the following: 

■ Identifying the risks. This means not 
just relying on SSL for a secure trans¬ 
port; you need to understand the 
dependencies and what’s going on 
behind the scenes. There may be 
attacks not only against the server, but 
against the client and the commerce 
protocols themselves to consider. 

■ Matching security policy with mecha¬ 
nisms. Authentication may not be nec¬ 
essary for all transactions. Compart- 
mentalization of data, users, and sys¬ 
tems needs to closely match policy. 
Different transactions may required 
different protection. 

■ Careful consideration of firewall and 
host security issues. These include the 
pros and cons, for example, of having a 
server behind, outside, replicated on 
both sides of, or between firewalls. 

■ Intrusion detection and audit. 
Identifying anomalous transactions 
may be difficult, but you can enlist the 
customer’s help by sending confirma¬ 
tions over an alternate channel, etc. 

Neuman also 
mentioned other 
concerns of elec¬ 
tronic com¬ 
merce, including 
reliability and 
service denial 
attacks, as well as 
insider attacks. 
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Real-World Security Practices 

JoAnn Perry, Independent Consultant, 
and Shabbir Safdar, Goldman, Sachs 
& Co. 

Summary by Dug Song 

Being a successful security professional in 
the business world requires as much poli¬ 
ticking and strategizing as technical work. 
Perry and Safdar offered keen insights 
into the problem of making security a 
real concern of your organization and of 
establishing the political clout needed to 
do your job effectively. 

The unfortunate reality is that most com¬ 
panies view information security as an 
annoying inconvenience. As a security 
professional, your challenge is to shape 
attitudes and opinions in your favor and 
to make security a crucial concern of 
business. 

To that end, Perry and Safdar offer the 
following hints: 

■ “Don’t be the naysayer.” People will be 
less likely to solicit your help if all you 
ever do is deny them. Be a solution 
provider vs. a gatekeeper, and demon¬ 
strate your end-user focus. 

■ “Talk to them in business terms.” 
Management needs to understand risk 
assessment in terms they can under¬ 
stand. Learn to talk the talk; under¬ 
stand the business side of the house as 
well as the technical. 

■ Motivate your peers. Do your own PR 
- increase the organization’s security 
awareness so your work isn’t a constant 
uphill battle. Join industry groups, 
share information with other security 
professionals. Security teams can test 
one anothers’ security. Even status 
reports, if made understandable to 
everyone from a business perspective, 
can be an opportunity for increasing 
awareness. The goal is to educate end- 
users and change the usually security- 
hostile corporate culture in your favor. 
Make allies. 


In terms of tech 
nical security’s 
best practices, 
they recom¬ 
mend these: 

■ Piggyback on 
standardiza¬ 
tion efforts. 

Make the 
most efficient 
use of your 
time! 

■ Find ways to 
make security 
cost-effective. 

(e.g., good Web authentication can 
enable low-cost customer service). 

■ Perform regular security audits, which 
can also be played politically to keep 
you evenhanded in functionality vs. 
security debates. 

■ Prepare your PR person for an 
incident. 

■ Build a supportive staff (e.g., a help 
desk staffed with interns to provide 
front-line support). 

■ Stay on the cutting edge. Pre-empt the 
hype of new products by testing and 
evaluating them before your end-users 
do. 



WORKS IN PROGRESS 

Qun Zhong: Enforcing Consistent Mobile 
Code Security Policy Across an Enterprise 
Network 

Peter Honeyman: Workstation 

Authentication 

<http://www.citi.umich.edu> 

Stefan Axelsson: A One-System Call 
Audit Trail and Its Effect on UNIX 
Security 

Randy Witlicki: Protocol Tunnels and 
Computer Network Security 

Mike Reiter: Crowds Anonymous Web 
Transactions 

Crowds are a fully implemented way to 
use encryption and request relay to make 
http requests anonymously. 
<http://www.research.att.com/projects/crowds> 

Alain Mayer: LPWA 

The Lucent Personalized Web Assistant is 
a tree proxy service that adds privacy by 
creating unique personal identities at 
Web sites without revealing personal 
information, such as your email address. 
<http://www.lpwa.com/> 

Peter Gutman: The Cryptlib 
Crypto/Security Architecture 

The cryptlib library provides an easy-to- 
use interface that allows any programmer 
to easily add strong encryption and 
authentication services to software. 
<http://www.cs.auckland.ac.nz/~pgut001/ 
cryptlib.html> 

Greg Rose: Opportunistic Encryption in 
Sendmail 

Rose has released patches for sendmail, 
incorporating encryption using his new 
stream cypher SOBER. 
<ftp://mcs.une.edu.au/pub/ssmail> 

Tadayoshi Kohno: A free SSH library 

The SSH library is not yet available due 
to export restrictions. 
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Greg Rose: SOBER - Fast Stream Cipher 

SOBER is a new stream cipher, designed 
to be small, fast, and secure. It is ideal for 
use in mobile phones as well as a wide 
range of encryption needs. 
<ftp://mcs.une.edu.au/pub/ssmail/sober.tar.gz> 

Raph Levien: Scaling trusted keys to the 
Internet 

Umesh Maheshwari: A Flexible 
Commerce Architecture 

Maheshwari presented a theoretical 
protocal architecture for electronic 
commerce. 

Wietse Venema: Vmailer 

Vmailer is a more secure and more easily 
configurable alternative to sendmail 
<http://www.vmailer.org/> 

Peter Honeyman: Smart Cards: Threat or 
Menace? 

Honeyman presented CITI’s progress in 
their research in the field of smart card 
implementation and use. 
<http://www.citi.umich.edu> 

Ian Goldberg: Pilot as Certificate 

Goldberg presented his plans for devel¬ 
oping the Palm Pilot as a replacement for 
smart card in public key certification. 
<http://www.isaac.cs.berkeley.edu/pilot/> 

Mudge: Pilot as Wardialer 

Mudge presented the LOphfs progress 
with their pilot development efforts. 
<http:www.IOpht.com> 



BOFS 

OpenBSD B0F 

Theo de Raadt, OpenBSD Project 

Theo de Raadt presented a history of the 
OpenBSD project, its current status, and 
its future directions, at one of the night’s 
most popular BOFs. 

OpenBSD formed as a spinoff of the 
NetBSD project, whose program was to 
port a freely available 4.4BSD UNIX to as 
many hardware platforms as possible. 
OpenBSD’s major differences from its 
progenitor include an emphasis on secu¬ 
rity and correctness, incorporation of 
strong cryptographic security systems 
(such as IPSEC, Kerberos, etc.), open 
access to source (via anonymous CVS), 
and incorporation of features from the 
competition (including FreeBSD, Linux, 
etc.). 

Over the years, de Raadt and company 
have performed at least two full security 
audits of the OS from the ground up. 
This included bugfixes, general code¬ 
cleanup, and proactive security changes 
that have had beneficial results all around 
(e.g., randomization of PIDs, protocol 
fixes, etc.). As a result, OpenBSD hasn’t 


had a single remote root vulnerability 
and only three reported localhost exploits 
in the past year - a record he challenges 
any major UNIX vendor to match. 

<http://www.openbsd.org/> 

Firewalls B0F 

While de Raadt’s OpenBSD BOF filled a 
small room to overflowing, the firewalls 
BOF almost filled a ballroom. As usual, 
Brent Chapman led the discussion, but 
with a surprise announcement. Brent had 
started the firewalls mailing list after the 
third USENIX Security Symposium (in 
Baltimore), but is now passing the list to 
a new home. Brent now works with an 
ADSL vendor and is no longer focused 
on firewalls, so the move makes sense. 

After the brief introduction, the BOF 
becomes a question-and-answer session, 
with the audience supplying both. 
Questions ranged from screening Java 
packets with firewalls (just look for the 
magic number OxCAFEBABE) to interop¬ 
erability of IPSEC encryption between 
different vendors’ implementations. The 
BOF lasted over two hours (still short of 
a record 3.5 hours set a couple of years 
before). 
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Why the Financial Community Rules 

NetSec Keynote, October 22, 1997 

I have had the privilege of broad experience in a number of areas relevant to 
today’s topic, in academe and in industry, in medical and in financial comput¬ 
ing, in distributed systems and in security management. I am formally trained 
as both an engineer and a biostatistician. I've been development manager for 
MIT’s Project Athena and an entrepreneur in financial security management. 

I’m now vice president of both CertCo, the high-end security company, and 
USENIX, the high-end engineering professional organization. I co-wrote The 
Web Security Sourcebook and chaired the first USENIX Symposium on Mobile 
and Location Independent Computing, the first USENIX Workshop on Electronic 
Commerce, and will do so for the first Public Key Infrastructure Implementors’ 
Workshop in August 1998. I say all that for one reason and one reason only, to 
help you estimate my biases so that you may correct for them. The wonderful 
thing about experience is that it calibrates your skepticism, and the wonderful 
thing about lack of experience is that it gives you design freedom. 


Given my biases, I am going to describe where the future of the security marketplace is 
and where it is not. I will argue that the financial community is and remains the place 
to look for “first light” from each new security technology. I will give you a rundown of 
whats new while I predict what little time is left for many of today’s products, purvey¬ 
ors, and regulators. I will argue that, in many ways, the party’s over for the security field 
as we know it now. I will range broadly because security, as a concept, is universal. 

“Nothing Is So Powerful As an Idea Whose Time Has Come” 

I begin by claiming that Voltaire’s famous dictum applies to security technology. On 
October 7, 1997, IBM took eight consecutive full-page ads in the Wall Street Journal to 
tout its electronic commerce expertise. On the final page, they listed the three require¬ 
ments of the business future; they were #1 security, #2 scalability, and #3 integration. 
IBM is right. Forrester, Gartner, META, Yankee, and all the other analysts agree - the 
single most important enabling technology for the electronic business, besides network 
connectivity itself, is security. In a different light, A. D. Little estimates that security, pri¬ 
vacy, and the legal issues of digital signature constitute over half of the quantifiable bar¬ 
riers to electronic commerce. 

There are whole venture funds whose investment focus is around security. Security 
startups are everywhere and so are security books. The word “security” is hardly rare in 
employment advertisements, and some companies even have a “corporate security offi¬ 
cer” to go with all the other CxO titles. You cannot walk a single aisle of a single trade 
show and not see the word “security” in screaming big type. The number of security 
meetings is preposterous, and yet all of them are packed. Only yesterday, a presidential 
commission recommended spending real money on security for the information sys¬ 
tems that run the country, and to do so jointly with the Departments of Defense and 
Commerce. This idea’s time has come. 

Andy Warhol was also right when he said, “In the future, everyone will each get 15 min¬ 
utes of fame.” Ten days ago today, the Web site at Forbes Magazine predicted that not 


24 


Security Special Issue ;login: 





one of today’s leading security specialty companies will survive because they all can 
easily be eclipsed by the platform vendors. Only the platform vendors can deliver secu¬ 
rity that is integrated enough to scale (remember the three requirements?), and when 
the platform vendors start supplying security, where will the innovative specialty add¬ 
ons be? As even the Justice Department knows, once something moves into the operat¬ 
ing system, the independent market for it collapses. Yes, security’s time may well have 
come, but in a Warhol world, that would mean that it is about time to go. 

Trust Management 

Security innovation has always had one foot in academia. The academic focus of “secu¬ 
rity” research today is the study of “trust management,” i.e., the study of how trust is 
created, propagated, circumscribed, stored, exchanged, accounted for, recalled, and 
adjudicated in an electronic world. This is both natural and mature. It is natural 
because security is a means and not an end; security procedure has to deliver enable¬ 
ment of something greater than itself or it is not worth the cost. It is mature because 
security technology is increasingly differentiated along cost-benefit lines: how much 
benefit (enablement) is delivered for how much cost (of integration). All the security 
technology that you can buy today enables some aspect of trust management, and the 
market is coming up with novel variations all the time. 

You can walk out of this hall and buy systems that use passwords that get local 
machines to trust you enough to let you in. You can buy smart cards that can do your 
cryptographic calculations for you, respond to challenges, hold your keys inviolable, 
or, more interestingly, have identities of their own and serve merely to introduce you 
to others on their own terms. You can buy biometric devices that look at your voice, 
your face, your retina, your fingerprint, or even the personal idiosyncrasies of how 
you learned to type and say, “Yep, that’s the guy.” You can get systems that are sufficient¬ 
ly hardened that you can trust them if for no other reason than they are so nearly use¬ 
less that no one would want to break in. You can still get your hands on security sys¬ 
tems in the raw and roll your own directly from source code - trust propagation for the 
connoisseur, as it were. 

For enough money, you can get systems that claim to package trust really pretty neatly, 
like a digital certificate supposedly enabling a “high-value, time-sensitive, Web-based, 
multiparty, globalized, transactional, and auditable business-to-business” deal. You can, 
anywhere, anytime, spin up virtual private networks that are trustworthy protectors of 
your confidentiality, however hostile the intervening wires are. You can even deliver pri¬ 
vacy between strangers - nearly a matter of creating trust in order to propagate it. You 
can put a document into the Eternity Service and trust that it can never be erased, or 
you can put it into a cryptographic filesystem and trust that it can never be found. 
Simple? Yes, academic and entrepreneurial segments alike are busy supplying many 
novel ways to propagate trust. They have it all wrong. 


Academic and entrepre¬ 
neurial segments alike are 
busy supplying many novel 
ways to propagate trust. 
They have it all wrong. 



Risk Management 

All of you who have ever taken a course in probability know that many problems are 
solved by calculating their dual - the probability of “not X” may be a whole lot more 
tractable than figuring Pr(X) directly. All of you in security-based startup companies 
know that making money requires making excitement, even if the excitement is some¬ 
body else’s public humiliation at the hands of an attacker. And all of you can agree 
that the more important something is, the more inevitable that it must be managed. 
Trust management is definitely exciting, but like most exciting ideas, it is not important 
(just as most important ideas are not exciting). What is important is risk management, 
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Risk management is going 
to take over as the 
dominant paradigm 
because risk management 
can delineate trust, but 
trust management cannot 
delineate risk. 


the sister, the dual of trust management. And it is risk management that is the part 
of financial services that will drive the security world from here on out, whether you 
realize it or not. 

Every financial firm of any substance has a formal Risk Management Department that 
consumes a lions share of the corporate IT budget. The financial world in its entirety is 
about packaging risk so that it can be bought and sold, i.e., so that risk can be finely 
enough graded to be managed at a profit proportional thereto. Everything from the 
lowly car loan to the most exotic derivative security is a risk-reward trade-off. Don’t for 
a minute underestimate the amount of money to be made on Wall Street, London, 
and/or Tokyo when you can invent a new way to package risk. The impact of Moore’s 
Law on the financial world has been nearly inestimable. Computing has made that 
world rich because it has enabled risk packaging to grow ever more precise, ever more 
differentiated, ever more manageable. You don’t have to understand forward swaptions, 
collateralized mortgage obligations, yield burning, or anything else to understand that 
risk management is where the money is. In this capitalist world, if something is where 
the money is, that something rules. Risk is that something. 

Security technology in both the here and now and in the heretofore has been about 
moving trust around as if risk is always undesirable and reliable trust management 
obviates the issue of risk in some general sense. It does not come close. In three years, 
the “trust-hauling” market will be somewhere on the down slope between legacy and 
dead. Risk management is going to take over as the dominant paradigm because risk 
management can delineate trust, but trust management cannot delineate risk. The 
Internet has made this so. 

The Internet is irresistible in one way in particular - it lowers barriers to entry on a 
global basis, and I mean global in both space and time. Obscure countries can leapfrog 
the established economies. Ever more important parts of the world’s economy will exist 
only in cyberspace, and lead times have entirely collapsed. Every professional fortune¬ 
teller is bidding geometric increases in the dollar volume of electronic commercial 
activity. But, and as everyone in this room knows, when there is enough booty avail¬ 
able, even absurdly difficult attacks become plausible. This is the world we are in. It will 
never be possible to really do the job of trust management any more than it is possible 
to really win an arms race. But risk management - that is doable and it is doable at a 
profit. The proof is all around us. 

Public Key vs. Secret Key Systems 

Numerologically, we are a score of years down this road. In 1978, a vintage security 
year, the remarkable papers by Rivest, Shamir and Adleman and Needham and 
Schroeder were published, both in CACM, as it happens. The former introduced com¬ 
pelling public key ideas and the latter unwittingly created Kerberos. The counterpoint 
between these two technologies is instructive. Both symmetric cryptosystems, like 
Kerberos, and asymmetric cryptosystems, like RSA, do the same thing - that is to say, 
they do key distribution - but the semantics are quite different. The fundamental secu¬ 
rity-enabling activity of a secret key system is to issue fresh keys at low latency and on 
demand. The fundamental security-enabling activity of an asymmetric key system is to 
verify the as-yet-unrevoked status of a key already in circulation, again with low latency 
and on demand. This is key management and it is a systems cost; a secret key system 
like Kerberos has incurred nearly all its costs by the moment of key issuance. By con¬ 
trast, a public key system incurs nearly all its costs with respect to key revocation. A 
rule of thumb might be that the cost of key issuance plus the cost of key revocation is a 
constant, something one might colloquially describe as just yet another version of “you 
can pay me now or you can pay me later.” 
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Because of the trade-offs between who pays for what part of the systems cost and who 
gets the benefit, secret key systems and public key systems have different fields of use. 
Secret key systems are fast and offer revocation at no marginal cost. Public key systems 
are slow, but they enable digital signature and thus enable proof of action, nonrepudia¬ 
tion, as it is called. Secret key systems are quite appropriately the default choice within 
an organization, and public key systems are similarly the default choice between orga¬ 
nizations, i.e., secret key for where security is an intramural concern intramurally arbi¬ 
trated, and public key for where security is extramural, thereby requiring recourse to a 
third party judge in cases of dispute. The seemingly relentless blurring of what is intra¬ 
mural and what is extramural will likely favor public key over time. 

However, a trust management paradigm says that a digital signature is only as valid as 
the key (in which it was signed) was at the moment of signature, which, in turn, is only 
as good as the procedural perfection of the certificate issuer and the timely transmis¬ 
sion of any subsequent revocation. These are high costs. In fact, the true costs of gener¬ 
al public key infrastructure are so extraordinarily high that only our collective igno¬ 
rance of those costs permits us to propel ourselves toward a general PKI as if it were a 
panacea, a cure-all. When, not if, the user community at large realizes this, we “security 
people” will have but two choices: compromise on (gloss over) the quality of trust that 
public key can deliver or back off from the claims of full trust - cheap. In other words, 
we’ll have to fit the benefit to the endurable cost or fit the cost to the requisite benefit. 
Because, as a rule of thumb, to halve the probability of loss, you have to at least double 
the cost of countermeasures, any finite tolerance of cost means an upper bound on how 
much security you can get. In the fullness of time, security technology will be evaluated 
on the same cost-benefit-risk trade-off that other technologies are evaluated on. This is 
the price of maturity; this is the price not yet paid. 

Do not misunderstand me; public key technology, secret key technology, security tech¬ 
nology in general are daily reaching new levels of protective capability. What they can¬ 
not protect against is being oversold. And they are being oversold. Why is that? 


As a rule of thumb, to 
halve the probability of 
loss, you have to at least 
double the cost of 
countermeasures. 



The Internet as Data Center 

The days when the Internet was a toy are gone, even if a high percentage of its new 
investors is coming in merely to avoid looking dowdy. To some extent, the real question 
on the table is, when does the Internet become more like the data center? And what does 
making the Internet more like the data center mean? At a minimum, it means metered 
use, once known as charge back. Take, for instance, spam email. Already discussions are 
widespread about requiring Internet postage; large ISPs will probably demand it, exist¬ 
ing postal services would love to sell it, and data centers, such as the financial giants, will 
get a better handle on what goes in and out the door. At least one Wall Street bank 
already does charge back for network bandwidth consumption, and their internal elec¬ 
tronic security regime plays a role in assigning those costs just as, in turn, their security 
group manages the user database via incremental updates rather than fresh full copies 
just so as to avoid bandwidth charges. That’s not postage, but it is close and it is now. 

But before you cheer “making the spammers pay,” be careful what you ask for because 
you might just get it. In a world of electronic postage, spammers will probably just pay 
the freight. It will slow them down a little, but electronic postage will probably just 
convert email spam into an electronic equivalent of today’s junk mail. As always, throt¬ 
tling demand by raising prices will bounce some people off the wire, but it is unlikely 
to be those who can pass their costs along to their clients. No doubt someone will think 
of making postage differential, based on who the sender is, just as it is in the paper 
world, and pretty soon postage for the Internet will be as savory a blend of price and 
convenience as postage for paper mail already is. 
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UNIX , however superior as 
a tool for people who 
appreciate knowing what 
to do and being able to do 
it for themselves, remains 
in a difficult position. 


Incremental use charges are but one example and are interesting mostly because they 
are a near term step in the direction of making the Internet into a data center. The fun¬ 
damental value of the data center remains the information it holds. The past few years 
have seen data warehousing, data mining, and now connection of the data center to the 
Web, data publishing, if you will. MVS, for example, has a really good Web server, and 
someone in the audience will have to show me what the difference really is between a 
1970s central time-share machine and an MVS Web server in a swarm of “thin clients” 
on fast networks. It certainly isn’t the direct wire connection - SSL simulates that well 
enough. It surely isn’t the management model; the MIS director who had declared 
defeat in desktop configuration management will, you can be sure, rejoice at getting 
control back. 

In the mainframe world, you move the computation to where the data are rather than, 
as in a client server world, moving the data to where the computation is. Web servers 
front-ending corporate databases attached to virtual private networks full of a universal 
client like a Web browser sure sounds like a resurgence of the data center to me. The 
IBM 390 is a good machine, and the Wintel cartel has pretty much ensured that no 
upstart will enter their space as it is currently constituted. From Wintel’s point of view, 
using all those desktop cycles for display functions is just fine. Can it be that simple? 

Nick Negroponte famously imagined what later became known as “The Negroponte 
Switch” in which he predicted that what had been wireless would become cabled and 
what had been cabled would become wireless. The cellular phone and cable TV have, 
just by themselves, made his prediction true. Well, here’s another switch - because of 
the Internet, who owns the data center and who owns the desktop will switch. IBM has 
long owned corporate computing while Wintel has consolidated its victory in the desk¬ 
top wars. But just as the wired vs. wireless world flipped, so will this one. 

Of all the computing companies, IBM is the most internally heterogenous, and it is 
actually the most committed to heterogeneity. It is teamed with Oracle and with 
Netscape, i.e., with the database and the thin but universal client. They will inherit the 
desktop. But Microsoft is after the server-side software market, and it has managed to 
entice HP into its parlor. With HP’s scalable industrial strength and quality, something 
Microsoft has never known, they will inherit the data center. This is the switch; watch 
for it. 

UNIX, however superior as a tool for people who appreciate knowing what to do and 
being able to do it for themselves, remains in a difficult position. I am reminded of 
Garret Hardin’s term “tragedy of the commons.” Hardin observed that what is owned 
in common and openly available to everyone will ultimately be vandalized or subdivid¬ 
ed. There are probably books to be written on that topic, but I submit that UNIX’s sta¬ 
tus as a commons remains both its enduring strength and its enduring vulnerability. 

Financial markets arguably made SUN what it is today and vice versa - SUN’s first big 
win, the first big demonstration that computing power had risen to such a degree that 
moving the data to where the computing is made sense, “the network is the computer” 
and all that. Financial markets, in the sense of traders going head to head, used that 
power to replace who you know with what you know and set off a technology-as- 
weapon metaphor that has overtaken most of the business world. Financial markets, in 
the sense of exchanges, now rely on a dense spread of computing that exceeds what 
most of us have to deal with; more than one major bank has 15,000 FTP jobs a night 
just moving data to or from the data center. Plenty of staff at the NYSE lose $1,000 
apiece for every 15 minutes the exchange is late opening due to IT unavailability. No 
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computing equipment is too expensive when trumped with “I can make that back on 
the first trade.” No small country runs its currency anymore. 

Before network technology, there was no question that the fundamental purpose of an 
exchange was to provide “an advantage of time and place” to those who would trade on 
it and, in so doing, establish efficiency and liquidity baselines against which others 
would be judged. Beginning first with the “paperwork crisis” in the 1960s and reaching 
a crescendo after the “crash of 1987,” the exchanges have been fully committed to elec¬ 
tronic commerce before that phrase meant anything. But since the Internet, time and 
place are meaningless, and the exchanges know it. They are working hard to make over¬ 
sight, fair play, and quality of service into new baselines. Clearly, security technology is, 
just as in that WSJ advertisement, is first in the list of their requirements, followed 
closely by scalability and integration. Just imagine how you would design the security 
infrastructure to mix the private networks of mortal enemy trading firms on the floor 
of an exchange, especially when someone working at Lehman Bros, today might be at 
Morgan Stanley tomorrow and everyone wants to use wireless communication. 

Bringing a Transactional Semantic to the Internet 

Security in a financial world market that is both nowhere and everywhere is a difficult 
thing to define well enough to solve. If there is anything to engineering as a discipline, 
it is that the heavy work is in getting the problem statement right. So, to return to my 
central premise, if new security technology is a result of investment and if the invest¬ 
ment in security technology is naturally centered within the financial community, what 
is the problem statement? If we get that right, we can predict the future. 

I submit that the problem statement is about bringing a transactional semantic to the 
Internet. This is not a new problem, but it is an as yet unsolved one. The existing finan¬ 
cial markets want transactions because transactions are what they are about and trans¬ 
actions are what they know. Upstarts like the payment vendors want to be the first to 
deliver transactions and disintermediate the financial firms. Technically smart legal 
beagles know that there is no transaction without recourse, no recourse without con¬ 
tract, no contract without nonrepudiation, and no nonrepudiation without digital sig¬ 
nature. Anyone who wants to do business on the Web needs transactions. 

So what do I mean by “transaction”? I mean a nonrepudiable communication between 
two parties who can each verify the time-, value-, and content-integrity of the commu¬ 
nication, who can rely on the confidentiality of that communication, who have assur¬ 
ance of the authenticity and authorization of their counterparty in the communication 
and who can, collectively, present all these evidences to third party adjudication should 
there be a need for recourse at any arbitrary time in the future. Every single part of that 
definition begs the question of security mechanism, and it is on that basis I claim that 
the security technology of tomorrow will be crafted in response to the unmet needs of 
financial markets today. 

Hal Varian, an economist and dean of the Information Management School at UC 
Berkeley, is of the opinion that what the Internet changes more than anything else is 
that it brings the possibility of auction to markets that never had that option. You can 
verify this yourself by looking at the number of ways in which price discovery through 
auction is already available on the Web. All these auctions need security technology 
because what makes an auction an auction is the ability to conclude a transaction that, 
by its own execution, “discovers” a price. An Internet auction is no different. In other 
words, the nature of the world’s economy is changed by the existence of the Internet, 
but on the condition that electronic transactions are up to the job. 


The security technology of 
tomorrow will be crafted in 
response to the unmet 
needs of financial markets 
today. 
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From both the merchant's 
and the bank's perspec¬ 
tives, getting rid of cash 
would be a huge win 
because physical 
processing of small dollar 
amounts often exceeds the 
profit margins on those 
sales. 


Your handwritten signature on a check is what, in principle, authorizes that funds move 
from A to B. But, from a banks point of view, actually verifying handwritten signatures 
is a cost that is worth bearing only if the cost of verification is less than the risk of loss. 
At the largest banks, the threshold dollar amount below which verification does not 
really happen is a closely guarded number, but it generally exceeds $20,000, and still 
they have platoons of people doing this all day, every day. Converting the means of sig¬ 
nature verification from a manual process into a machineable one would radically 
change the economics of check processing. It would add billions to the collective bot¬ 
tom lines and do it from the cost-avoidance side of the ledger. 

But that is not all. Some $300B of payments are made every day of which but $60B are 
in the form of checks; the balance is largely in cash transactions of $5 or less. From 
both the merchant’s and the bank’s perspectives, getting rid of cash would be a huge 
win because physical processing of small dollar amounts often exceeds the profit mar¬ 
gins on those sales. The consumer may well adopt cashless payment out of some sense 
of convenience, but the financial side of the house will enable it to avoid costs. 

Payment on the Web has sparked numerous startups with a wealth of different mecha¬ 
nisms. Although it is too late for you to enter this market, it is not too late for those 
payment systems vendors to rethink what they are trying to do. As it is, all of them are 
suffering because the volume of Web-based retail business has not picked up as fast as 
their business plans had hoped. For the retail customer, the only thing the Web offers is 
product discovery; a good print catalog and an 800 number are otherwise hard to beat. 
It is clear that the real money in Web commerce is in business-to-business commerce, 
but there the supply chain has a lot more complication, and the kinds of security 
mechanisms need to be somewhat different from those for, say, buying a toaster oven or 
a sweater. Whereas retail commerce is about small dollar amounts and stranger-to- 
stranger transactions through a financial intermediary like a credit card company, busi¬ 
ness-to-business is more about relationships, the dollar value of the sale is much bigger, 
and banks play a direct role (through letters of credit, collateralized bills of lading, etc.). 

This kind of commerce does not have a good solution yet. If you want to sell into this 
market, be aware that the customer will buy either to avoid costs she has now or to 
make revenue he doesn’t have yet. In the case of saving costs, you’ll have to sell the cus¬ 
tomers the technology on a turnkey basis - they will not cut you into the transactional 
revenue stream. If you can really show that your technology will make them revenue 
they did not have a chance to make otherwise, you may be able to get a piece of the 
revenue stream, but do not underestimate the cost-avoidance focus of big buyers and 
sellers. As far out as 2005, over half the Internet transactions will be transactions con¬ 
verted from paper and credit/debit cards, not new transactions. When selling into a 
cost-averse market you automate rather than revolutionize, and you do not get a piece 
of the action. 

“Disintermediating the Banks” 

Everyone likes to talk about “disintermediating the banks,” that is, making the interme¬ 
diary role of banks in commerce less essential by performing that service in some other 
way. Bill Gates, for example, is widely quoted as saying that “Banks are dinosaurs.” At 
the high end, they are not dinosaurs and they are not about to be disintermediated. The 
banks have a natural affection for their income streams, but that doesn’t prevent disin¬ 
termediation. Most wiseguys trying to disintermediate the banks misunderstand what 
banks do. This is what they do: they interpose their balance sheet between the expecta¬ 
tions of the counterparties to a transaction and the risk of default on either of their 
parts. They undertake stop-loss protections against credit risk, insolvency, operational 
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failure, currency fluctuation, and diversion of funds delivery. In other words, they man¬ 
age risk because they can absorb loss. An electronic commerce payment technology 
vendor cannot absorb loss, so it cannot and will not disintermediate the banks. 

Think of it this way: all public key technology is about making a digital signature verifi¬ 
able, i.e., it is about quality control and guarantee on the signature itself. This is a stun¬ 
ning thing, but it is not the whole equation. The intermediation role that banks play is 
to guarantee the transaction, i.e., it is broader than just the verification of a signature. 
The bank’s know-how and its balance sheet are not something that can be replaced by a 
cryptographic calculation. The ability to avoid loss never completely makes up for the 
ability to absorb loss. The cryptography guarantees the signature. The bank’s capital 
guarantees the transaction. Risk control encapsulates trust. 

In the midst of this, you might ask “What are the standards?” in the sense of “What do 
the formal standards groups have to say?” The banking world is regulation rich and 
standards rich, too. This begs an interesting question - “Which standards matter?” The 
world of the Internet is making some of the banking-centric standards passe, but, 
unlike the combination of standards and regulations the banks are familiar with, the 
standards groups of the Internet cannot take on accountability for the implications of 
conformance/nonconformance, though they continue to define it for others. This 
makes Internet standards quite a bit more difficult to swallow because there is no 
accountability, nor can there be. The absence of enforcement probably guarantees that 
the only Internet standards that will really get attention are those that promote interop¬ 
erability across jurisdictional boundaries. Oddly, this is all the pioneers in the Internet 
wanted. 

What the banks want, and I assure you they will get, is a set of cryptographically 
sophisticated tools that move the risks of the Internet from open-ended to estimable. In 
a sense, this is like insurability. It is probably apocryphal, but the story goes that a 
major investment firm with a Web commerce idea went to a big insurance company to 
seek insurance. The conversation supposedly went like this: 

“How big is the potential loss?” 

“We don’t know.” 

“How likely is a loss to occur?” 

“We don’t know.” 

“How much is your company worth?” 

“This much.” 

“That’s the premium; send it in.” 

Whether true or not, it illustrates the point - the issue was getting a handle on the risk 
such that it could be priced. Let me make a prediction in this regard. Every one of you 
who has tried to sell security technology has discovered that the only willing customers 
are those who either (l) have just been embarrassed in public or (2) have just learned 
that they are facing a management audit. Everyone else is an unwilling customer. We’ve 
been dumb about this; we’ve tried to sell security as a means to establish trust but we’ve 
done it by preaching about risks. It’s no damned wonder that we haven’t sold much. I 
know I have often wondered if my market might not explode if I could just get one of 
the big loss-prevention insurers to make good security practices and technology into an 
underwriting standard. Then, just like with fire insurance and the question of do you 
have sprinklers or not, everyone would be forced to confront whether they wanted to 


What the banks want, and 
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Internet from open-ended 
to estimable. 
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pay for security or pay for nonsecurity. I was, and am, pretty confident that the insurers 
could soften up my targets a lot better than I could. 

Let me tell you, they are about to. Insurability of Web commerce is essential, and no 
insurer is going to accept “We don’t know” as an answer. They will say “Send it all in” 
and they’ll mean it. The demand side for security technology is about to explode, but it 
isn’t quite the security technology we have on hand. 

Trusted Third Parties 

But there is another point: if a digital signature has the uniquely irreplaceable property 
of providing proof to a third party judge, then the role of a “trusted third party” is 
going to become more important over time, not less. Think of it this way: when I get a 
certificate issued to me by a certifying authority, I do have some risk around whether 
the CA is well operated or not. This includes the probability they will issue a certificate 
with my public key but someone else’s name and whether, when I tell them that my key 
has been compromised, they will spring into decisive action. Most of that risk I can 
handle by a combination of due diligence and contract. 

However, when I give my certificate to you and say, “Hi, I’m here from Central Services 
to fix your system,” you are in a risky position. You have to say, “Is this certificate 
valid?” That means you have to check that the certificate is not listed as revoked, that 
the signature on the certificate is well formed, that the certificate authority that 
issued this certificate itself has an identity certificate that is validly signed, that the 
certificate authority is itself not in any trouble with revocation, and so on and so forth, 
recursively. 

In other words, this exceeds the intellectual and programmatic capacity of most certifi¬ 
cate recipients. This means that most recipients cannot themselves rely on the security 
technology to establish trust beyond the shadow of a doubt. Instead, if recipients are 
smart, they will turn again to the insurance world just as risk holders have done when¬ 
ever they cannot afford to sustain the consequences of a remotely unlikely event. For 
the insurer, he will underwrite a guarantee on the transaction for a fee that will reflect 
his assessment of the CA’s practices, the kind of transaction undertaken, the dollar 
amounts involved, etc. This will seem sensible to all parties because it is so familiar. 

This is risk management underwritten by financial intermediaries. This is where we will 
shortly be. 

There is one potential fly in this ointment, and I do not intend to dwell on it, but I can¬ 
not get this far and not mention the risks of building up strong security apparatuses 
only to have them undermined by key escrow policies, whether by companies or by 
governments. If you will, corporate policies and laws alike have always been defined in 
a territorial way that relies on clearly identifiable borders, physical locations where the 
policy or the law come to an end. But, as I have said, in the electronic world, borders 
are meaningless. In some sense, sovereignty, based as it was on the idea of a border, is 
less meaningful now than it has been for some centuries. In its place is a different kind 
of sovereignty, one that recognizes that the only borders that are defensible in an elec¬ 
tronic world are electronic borders, that is to say, that electronic borders are crypto¬ 
graphic ones. As such, the debate over who may or may not have a key known only to 
themselves is a proxy discussion for who may or may not have sovereignty within the 
potentially large number of cryptographically defined spaces. 

There are some very hard questions yet unanswered. Compromised keys are revoked 
effective not to the moment of suspicion of compromise, but rather retroactively to the 
last known time when the key was safe. In the case of escrow, should not a key’s owner 
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retroactively revoke it to the moment of its seizure from escrow if the owner discovers 
that it has been so seized? Or if a revoked key is revoked only by the action of the certi¬ 
fying authority signing a revocation notice in a special key, can that revocation-signing 
key itself ever be revoked? If it could, would that not invalidate (reverse) any revoca¬ 
tions signed in it, and what does that mean? I offer these only to encourage you not to 
equate my argument about the near-inevitability of investment in public key technolo¬ 
gy and digital-signature-dependent activities with any argument over infallibility of the 
technology or our understanding of it. These questions will be settled one way or 
another, but they remain open as we speak here today. 

I have tried to lay out my estimation on which way the tide is running and which 
moons gravity matters. I could be completely wrong or merely overstating what my 
biases bring me, but I think not. I think that just as the best estimate of tomorrows 
weather is todays, the best estimate of how the Internet and the financial behemoths 
will interact is for the Internet to be driven, perhaps only as a side effect, by the cost- 
reduction and profit-incented strategies of those financial behemoths. They already 
transcend national boundaries, and their investment decisions do run the world, 
including our part of it. Were this to get enough investment, it might make security a 
solved problem, at least as I define “solved” to mean “consistent with risk management 
in the insurance style.” Because that would collapse the market for novel security add¬ 
ons, I strongly suggest that, as you prepare your business plans, you figure out how to 
be, as Tom Lehrer would say, a doctor specializing in diseases of the rich. 

This is a very exciting time, and it is a privilege to be a part of it, both for me and for 
you. When we are all relics in rocking chairs, we will still know that we were present at 
the creation. 


I strongly suggest that, as 
you prepare your business 
plans, you figure out how 
to be, as Tom Lehrer would 
say, a doctor specializing 
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internet anonymizing 
techniques 

I didn’t think much about network anonymity until I attended a panel discus¬ 
sion on Web privacy and anonymity at the February 1997 Internet Society 
Symposium on Network and Distributed System Security. The consensus on pri¬ 
vacy was, well, that there just isn't much and that commercial interests are 
unlikely to champion the cause. The panelists exhorted the audience to take 
notice, and I listened. 

Apparently, many people have heard the call! Our special issue editor mentioned a sim¬ 
ilar panel at a USENIX conference that I missed. Several different projects have come to 
light in the past couple of years, and some of them are mature enough to see use on 
your own networks - whether you’re ready for that or not. In this article, I’ll discuss the 
most promising and visible anonymizing technologies and try to give you a sense of 
their strengths and weaknesses. 

Anonymity 

The first thing to know is that anonymity isn’t the same as confidentiality. Network 
stream secrecy can be pretty much guaranteed with appropriate cryptography, even 
though technical issues such as key distribution infrastructures and political ones such 
as exportability and key escrow always seem to overshadow the underlying techniques. 
If this article were about secrecy, I’d continue with praises of PGP, Kerberos, SSL, SSH, 
IPSEC, and the like. 

Network anonymity instead tries to protect the identities of communication endpoints. 
Let’s say you’re working in a nuclear plant and come to believe that your boss is illegally 
siphoning off the safety budget. You decide to report it to the US Federal Bureau of 
Investigation, so you type a URL into your browser: <https://www.fbi.gov>. No luck, they 
don’t offer encrypted Web service, so you back off and resolve to try again from home 
later. But you’ve already tipped off the network administrator, your boss’s brother, Ned, 
who sees the connection attempt from your PC to <www.fbi.gov> in his logs. Later, as 
you’re driving home in the heavy rain, the soundtrack becomes rumbling and disso¬ 
nant. You realize that your brakes aren’t working, and the quick cut to the next scene 
cruelly truncates your cross-armed shriek. 

How can you give the story a less cinematic ending? Receiver anonymity would help: if 
Ned couldn’t tell that the connection attempt is to <www.fbi.gov> (the receiver), then you 
wouldn’t be nearly as exposed. Even better might be sender anonymity, so that no one 
would know your PC, instead of your coworker’s PC, is sending the initial connection 
request. Of course, the best protection would be the combination of sender and receiv¬ 
er anonymity, so that Ned could see only that some computer on his network is 
attempting a connection to some remote site. 

Anon.penet.fi 

Even though it’s been dead for two years now, it’s hard to describe anonymous net¬ 
working without mentioning the remailing service at <anon.penet.fi>. Penet was a simple 
and easy-to-use double-blind email forwarding service, run in Finland by Johan 
Helsingius, that kept its mapping between real and anonymous email addresses secret. 

If you contacted the FBI through <anon.penet.fi>, Ned could only see that your PC had 
contacted Penet. Similarly, Ned’s fiance’s crooked sister Fran - the FBI postmaster - 
could see only a connection from Penet, not one from the nuclear plant. 

The obvious downside to the scheme is that you don’t really know Penet’s relationship 
to Ned and Fran, so you just have to hope Penet isn’t inclined or able to betray your 


34 


Security Special Issue ;login: 





identity. Unfortunately, that was Penet’s undoing: even though it was most certainly 
disinclined, it was indeed able to betray identities, and so ultimately a legal challenge 
forced it to do so. After one identity was revealed and more were demanded, Helsingius 
shut the service down. 

The Anonymizer 

The Anonymizer <www.anonymizer.com> is to the Web what Penet was to email: a simple 
and easy-to-use forwarding service. To fetch the FBI Web page, you could load up 
<http://www.anonymizer.com:8080/www.fbi.gov>. Ned would see a network connection to the 
Anonymizer, and Fran would see a connection from the Anonymizer, and neither 
would know precisely what was happening. But again, you'd have to trust the 
Anonymizer not to betray your identity; it certainly is able to, at least while your HTTP 
session is in progress. 

Actually, the Anonymizer remembers the session much longer than is technically 
required. According to the Anonymizer user agreement, “Usage logs are usually kept for 
fifteen (15) days for maintenance purposes, monitoring Spamming and monitoring 
abuses of netiquette. Any relevant portion(s) of such logs may be kept for as long as 
needed to stop the abuses.” So the Anonymizer can be raided just as Penet was. 

Nonetheless, the Anonymizer is probably the most heavily used anonymizing service 
today. Although its fine at hiding client identities from Web servers, it’s not so good at 
hiding the server identities from the network segment between the Web client and the 
Anonymizer. For example, Ned can see “www.fbi.gov” just by unpacking the URL you 
sent to the Anonymizer above. Most proxies and firewalls capture and log URLs rou¬ 
tinely. 

The Anonymizer is the first and only Internet privacy service with a price tag. 
Nonpaying users like me are awarded a bonus 30-60 second delay per page, giving us 
time to ponder our customer status while gazing at the (quickly delivered) enticement 
to upgrade. And they do promise a solution to the server hiding problem soon, “for the 
affordable price of $50.00,” probably by encrypting the target URL on the way to the 
Anonymizer. 

Mixmaster and Nym.alias.net 

The email Mixmaster is probably the most untraceable remailing technology to date. 

It’s an implementation of an idea called “mixing” that was invented and expounded in 
the early 1980s academic press by David Chaum (currently chief technology officer of 
Digicash Inc.). Here’s the idea: given a would-be anonymous message, first choose a 
route through a series of special forwarding nodes from the message source to its desti¬ 
nation, and then wrap some extra layers of data around the message. To form the 
innermost layer, concatenate the name of the last node - the node one hop away from 
the message destination - with the original message, and encrypt the result with the 
public key of the second-to-last node in the route. 

Now think about this bundle: it has one layer of routing data prepended to the original 
message, and it’s encrypted with a key possessed by the second-to-last node in the 
route. So if the bundle were to somehow arrive at the second-to-last node, it could be 
decrypted there, and that one layer of routing data would be enough to get the original 
message to its final destination. 

If you repeat this sort of encapsulation, this time with the third-to-last node, you can 
see what happens. You now have a bundle that can be decrypted only by the third-to- 
last node. Once decrypted there, the interior can be sent on to the second-to-last node. 
At the same time, the third-to-last node can’t read the interior of the bundle, because 
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that part is encrypted with a different key. So each node on the path can see only one 
hop in either direction. 

If you use the Mixmaster to transmit your outgoing email through one Mix hop, the 
destination will see a connection only from that Mix hop - sort of like an encrypting 
Anonymizer. Most people forward through two or more hops so no single Mix node 
experiences both the sender IP address and receiver IP address of a single message. In 
other words, using two or more hops keeps the sender anonymous to every hop but the 
first and the receiver anonymous to every hop but the last. 

Your identity is best hidden if you actually run your own Mixmaster forwarding node 
and direct your own outgoing mail through it. Then the first hop is yours, and because 
only the first hop can see the true sender IP address, this offers excellent sender protec¬ 
tion. But you really do have to carry other sites' traffic, too. If everyone knows that your 
forwarding node serves only your personal traffic, you haven’t gained anything by using 
it. However, running a busy forwarding node is fairly conspicuous, and it’s hard to say 
how Ned would react to that kind of traffic. 

If you’re worried about an attacker powerful enough to monitor several nodes simulta¬ 
neously, then you also have to worry about timing attacks and other subtle correlations. 
In the extreme case, suppose the Mix network is completely idle until you send your 
message. Then even though they can’t undo the layered encryption, Ned and Fran can 
locate your route’s endpoints just by watching the right part of the network. After all, 
each Mix packet must be part of your message. Mixmaster resists attacks like this with 
batching/reordering: each forwarding node keeps quiet - absorbing messages but not 
transmitting them - until its outbound buffer overflows, at which point the node emits 
a randomly chosen outbound message to its next hop. 

There’s a slick gateway to the Mixmaster available at the Anonymizer Web site men¬ 
tioned above. Also, check out <http://www.cs.berkeley.edu/~raph/remailer-list.html> for links to 
Mixmaster sources and documentation, as well as plenty of information about other 
types of remailers and privacy tools. 

But wait - when you send the FBI anonymous email with the Mixmaster, how can they 
reply to you? Well, they can’t, unless you explicitly tell them how to do it. One tech¬ 
nique is just to tell them to send their reply to the newsgroup alt.anonymous.messages 
with the subject “74847.” Ok, it’s pretty untraceable, but also expensive and unreliable. 
Here’s a better idea: you already know how to build an untraceable Mix route from you 
to the FBI, so why not build one from the FBI to you while you’re at it and send it 
along with your original message? Because it’s a Mix route, they can only tell what the 
first link is on the return path, so it doesn’t endanger you. 

Mixmaster doesn’t directly support including return paths in messages, but there’s a 
third-party solution that works well with Mixmaster and other remailers. The 
“nymserver” <nym.alias.net> lets people build “reply blocks” in advance and register them 
under a pseudonym stored in the <nym.alias.net> database. For instance, you could regis¬ 
ter a Mixmaster return path to your site under the name <NukeRat@nym.alias.net> and just 
include that address in your original mail. Then, when the FBI replies to you as 
<NukeRat@nym.alias.net>, the mail will reach you even though neither they nor 
<nym.alias.net> see the whole return path. Complete instructions are available at 
<http://www.es. berkeley.edu/~raph/ri. a. n.htmlx 

Onion Routing 

Researchers at the US Naval Research Laboratory have adapted Mixing technology to 
provide sender and receiver anonymity to other applications in a system called Onion 
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Routing. The “onions” are the layered encrypted messages, and the “onion routers” are 
the forwarding nodes. The first Onion Routing papers described support for Web traf¬ 
fic, email, and rlogin, and they have since announced development efforts for many 
other protocols as well: Telnet, FTP, NNTP, DNS, NFS, among others. But to support 
interactive applications with even a hope of tolerable latency, the batching and reorder¬ 
ing technique of the Mixmaster is out of the question. This means that coordinated 
observation of the network links connecting onion routers could reveal a connection’s 
route and so betray the connection’s source or destination. Therefore, it’s important to 
ensure that the links between onion routers can’t be simultaneously sniffed. The easiest 
approach is to put onion routers on different LANs in different buildings with different 
network administrators - ones who would be unlikely to collude. 

Interactive applications need two-way communication over the entire route, but 
Mixing is pretty much a one-way technique. We’ve seen how to handle this with a reply 
block, but onion routers instead create and maintain connection state as the onions 
flow through the routers. Once a connection has been built using Mix-style layered 
encryption, subsequent messages can flow in either direction along the chosen route. 
Then the routers switch to secret-key cryptography for the connection, because it’s so 
much faster than public-key cryptography. 

To access the FBI Web site through an onion network, you first have to set your brows¬ 
er’s HTTP proxy to point to an onion network entry point (an “application proxy”). 
Then when you attempt to load a page, the onion router sanitizes your request by 
removing revealing headers, builds a connection as described, and lets the two end¬ 
points communicate freely through it. Like the Mixmaster, the best protection results 
from having a trusted connection between you and an onion router, such as by running 
an onion router on your local workstation. 

In short, it’s much harder for Ned to track you down through an onion network than 
through the Anonymizer, but it requires a lot more infrastructure support, too. 
Although not yet widely deployed, Onion Routing is a technology to keep your eye on. 
Look to <http://www.onion-router.net/> for current status and other useful information. 
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Crowds 

Another general-purpose anonymizing tool called Crowds is in development at AT&T 
Research. Its slogan, “Anonymity Loves Company,” reveals a strategic similarity to the 
Mixmaster and Onion Routing in the sense that its untraceability improves as more 
and more people use it. But Crowds doesn’t rely on Mixing at all. 

Whereas Mixmaster and Onion Routing randomly construct a new and independent 
route for every connection, Crowds randomly assigns a native route to each Crowds 
“jondo” (John Doe, Crowdspeak for “forwarding node”). Each jondo has two different 
input streams. The local stream contains requests for anonymous site access from a 
local user - these follow the native route - and the remote stream contains requests 
that are merely visiting the jondo from elsewhere. When requests leave a jondo, the 
subsequent jondos can’t tell whether they’re following their predecessor’s native route 
or some other route that just included the predecessor, so neither can they tell who is 
really sending the message. 

Every visited jondo does see the ultimate destination of a connection request, so 
Crowds doesn’t provide connection receiver anonymity. But this allows it to route 
around broken nodes automatically. To prevent snooping between nodes, Crowds 
employs secret-key encryption with one key per route. Like Onion Routing, Crowds 
builds connection state into the jondos as their routes are built in order to support sub¬ 
sequent two-way communication. And also like Onion Routing, Crowds is vulnerable 
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to the coordinated observation of jondos, so the same remarks about separating onion 
routers apply to Crowds jondos. 

Crowds has another timing vulnerability that its designers have worked hard to mini¬ 
mize. The problem is that the untraceability of a route follows from each jondo not 
knowing its position on a route, i.e., whether it's the second or third hop or greater. If a 
malicious jondo knew that it was the second hop on a route, then the predecessor 
jondo (which it can see) would be the entry point of the supposedly anonymous 
sender. 

Now suppose that Ned has installed a malicious jondo in a Crowds network in order to 
catch you red-handed. You use Crowds to load up the FBI Web site, and Ned’s jondo 
notices your outbound HTTP GET. Right as his jondo delivers the last byte of the main 
Web page, it starts a timer and measures the amount of time that elapses until it sees a 
GET for the first embedded image in the page. This elapsed time is a strong hint as to 
the number of Crowds jondos preceding it. 

Crowds does try to defeat this kind of attack. In the previous example, Crowds searches 
for the image tags in the HTML itself and delivers the referenced images along with the 
original document. Because the first jondo never has to ask for them, there’s no reliable 
second event for a malicious jondo to time. 

Predicting client behavior and compensating for it in proxies is difficult. At present, 
Crowds supports only Web traffic, but one can imagine proxies for other types of appli¬ 
cations, too. A version of Crowds written in Perl can be obtained by US and Canadian 
citizens at <http://www.research.att.com/projects/crowds/>. 


The Lucent Personal Web Assistant 

LPWA doesn’t really deal in sender or receiver anonymity directly. Instead, it combats 
linkability - the ability of adversaries to correlate your activities at various Web sites 
and draw conclusions that you’d perhaps prefer to keep private. Have you ever deliber¬ 
ately misspelled your name on a registration form in order to see how much junk mail 
it generates? LPWA works on the same principle by automatically deriving a unique 
pseudonym for you at each site you visit and presenting that identity for you. 

For example, the New York Times site gives you access to much of that newspaper as 
long as you register. LPWA can automatically generate your New York Times name and 
password, and even a unique email address where you can receive return mail. For 
example: after setting your browser to use the LPWA proxy (lpwa.com:8000), go to 
<http://www.nytimes.com>. LPWA will interpose a couple of pages describing the LPWA 
service and asking you for your real identity (or at least the one from which your many 
pseudonyms will be derived). Then when LPWA sends you on to your original URL 
and the New York Times site asks you to register, just give the string “\u” as your sub¬ 
scriber ID, “\p” as your password, and “\@” as your email address. LPWA will intercept 
those codes and replace them with the nonsensical pseudonyms it uses for you at that 
site. At one site, my pseudonymous username and password are u elnadkv5” and 
“dphagcal,” and my email address is <lqnb2bx4tdzrv/@lpwa.com>. 

A paper describing LPWA shows how the pseudonyms are computed from a collision- 
resistant hash function of your real LPWA username/password and a site name. Given 
current knowledge about hash functions, it’s computationally infeasible for others, 
including LPWA, to produce a real username given only a pseudonym at a site. In other 
words, there doesn’t have to be any raidable database at all. In spite of that, LPWA does 
keep track of its existing mappings somehow. Otherwise, lpwa.com wouldn’t be able to 
forward mail for <lqnb2bx4tdzrv/@lpwa.com> to <dm@cs.bu.edu>. Incidentally, LPWA calls 
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these pseudonymous email addresses “target-revocable”: because you leave a different 
email address at every site, you can later refuse email from any one of them just by 
adding your pseudonym there to your mail filter’s reject list. 

Should you trust LPWA not to gather up all of the correlations between people inter¬ 
ested in protecting their privacy? Such a mailing list might fetch noticeably higher 
prices than others! Well, you could apply LPWA’s techniques right on your own equip¬ 
ment instead of using their central proxy. In fact, by coding things up right, you could 
combine the protection of Onion Routing or Crowds with LPWA rewriting. But at this 
point, I’m afraid you would indeed have to code it up yourself. The LPWA maintainers 
currently classify it as a “technology demonstration” only, and source code doesn’t 
appear to be currently available: patent pending! 

JANUS 

What if you want to publish Web pages without revealing the name of your server? 
JANUS is a service of the Fernuniversitaet Hagen that behaves like the Anonymizer, but 
it hides receiver identities instead of sender identities. How can clients request pages if 
the page locations are secret? JANUS handles this by encrypting and decrypting URLs 
on the fly. For instance, <http://www.fbi.gov> becomes 

<http://janus.fernuni-hagen.de/janus_encrypted/MTBFmQyDODyEJMpSV5zstQPNsnllC95q9BYRhlhbzm50goH 
vGO0uktoNmuMnBh4PRVXPO97xKiYNYh$xlPNPybu35XaLh3XaSilqpU0Y$TbHt4Bgl9biveLroOHLtu9vt7l=>. 
When you load up that URL, JANUS decrypts the request to see <www.fbi.gov>. It for¬ 
wards the request and returns the result, encrypting and rewriting all of the URLs in 
the FBI page so that Ned’s network logs show only a connection to JANUS, and even 
the URLs recorded in his logs don’t tip him off. But only the URLs are encrypted, so if 
Ned snoops the actual data stream, he won’t be fooled. And because you don’t have the 
JANUS secret key, you can’t come up with the encrypted URL yourself - you have to 
ask JANUS for it or somehow know it in advance. So JANUS isn’t really that useful for 
your predicament. It’s really designed for anonymous publishing. 

The standard cautions about single-hop forwarding apply here; coordinated and well- 
placed sniffers could determine the mapping for a site pretty easily. See 
<http://janus.fernuni-hagen.de/> for instructions and more information. 

Conclusion 

So what are you going to do? You really have only a couple of choices today. You can try 
contacting the FBI through the Anonymizer and hope Ned isn’t logging requested 
URLs and isn’t snooping your data stream. Otherwise, you have to install special soft¬ 
ware and become part of an anonymous forwarding network, successfully convincing 
others to forward through your site, before you can send anonymously with any confi¬ 
dence. It’s probably easiest to just make a call from a pay phone on the way home. You 
might get soaked, but Ned won’t notice. 

I’ve described only technical approaches to anonymity, but there are strongly supported 
voluntary cooperation privacy standards in development. See <http://www.w3.org/> for 
information about the Platform for Internet Content Selection (PICS), the Platform for 
Privacy Preferences (P3P), and other privacy strategies. 

I hope this article has given you a sense of today’s Internet anonymizing technology. As 
the author, I get to take advantage of this opportunity to mention my own work, too: 
an investigation of anonymity as a networking primitive. Check out 
<http://www.cs.bu.edu/students/grads/dm/anon.html> for information on this as well as links to 
other sites. Unfortunately, my system is still in initial development, so I don’t think it 
warrants more attention in this article. Maybe next time! 
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in Windows NT 5.0 
domains 

Enterprise networks using Windows NT are growing in size and complexity. 
Windows NT 5.0 uses the Kerberos Version 5 authentication protocol and the 
Active Directory for network security in Windows NT domains. The Windows NT 
implementation of the Kerberos Version 5 protocol is based on RFC 1510, 
which has gone through a wide industry review and is well known in the securi¬ 
ty community [1]. Kerberos authentication provides many features that support 
performance and security objectives for Enterprise networks. Microsoft’s imple¬ 
mentation will support any RFC 1510-compliant clients, but will be required 
for full support of Windows NT networks because the Microsoft version includes 
permitted extensions to the standard. 


Windows NT 5.0 integrates the Kerberos protocol into the existing Windows NT dis¬ 
tributed security model. Windows NT uses the extensibility features of the protocol, as 
have other security architectures, such as DCE and SESAME [2]. The Kerberos protocol 
is just one of the security protocols supported in Windows NT 5.0. Others include 
NTLM for backward compatibility, SSL and the IETF standard Transport Layer 
Security (TLS) for public-key authentication, Simple Protected Negotiation (SPNEGO) 
of security mechanisms, and IP security (IPsec) for network layer security using either 
shared-key or public-key authentication. 

Windows NT Distributed Security Model 

Windows NT has a distributed security model for network services based on three fun¬ 
damental components. First, every workstation and server has a direct trust path to a 
Domain Controller (DC) for the domain in which it is a member. The trust path is 
implemented by the Netlogon service through an authenticated RPC connection to the 
trusted domain authority, namely, the DC. A secure channel extends to other Windows 
NT domains through interdomain trust relationships. The secure channel is used to 
obtain and verify security information, including Security Identifiers (SIDs) for users 
and groups. 

Second, network services impersonate the client’s security context before carrying out 
requested operations. Impersonation is based on the security access token created by 
the Local Security Authority (LSA) that represents the client’s authorizations on the 
server computer. A server thread impersonates the client and executes with the autho¬ 
rization of the client rather than the security identity of the server. Impersonation is 
supported by all Windows NT services, including, for example, the CIFS/SMB remote 
fileserver service. Authenticated RPC and DCOM security support impersonation for 
distributed applications. BackOffice services like Exchange, SNA Server, and Internet 
Information Server also use impersonation. 

Third, the Windows NT kernel supports object-based access control by verifying SIDs 
in the access token against granted access rights defined in the access control list (ACL) 
on an object. Every object in Windows NT (registry keys, NTFS files and directories, 
file shares, kernel objects, print queues, etc.) has an object-specific ACL. The Windows 
NT kernel performs an access check on every attempt to open a handle to an object. 
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Access control and auditing are managed by setting the security properties of the object 
to grant permissions to a user, or preferably a group. Authorization is centrally man¬ 
aged by adding users to the Windows NT groups that are granted the appropriate 
access rights. 

These components of the distributed security model are an important part of all secure 
application servers on Windows NT. Windows NT 5.0 adds new security protocols, 
including public-key client authentication using SSL/TLS and Kerberos Version 5, 
which are integrated into the security model. 

Integrated Kerberos Authentication 

Windows NT 5.0 integrates Kerberos authentication into Windows NT domains for 
single sign-on and support for the Windows NT distributed security model. The 
Kerberos protocol provides mutual authentication, faster authentication, and transitive 
trust for authentication anywhere in a tree of Windows NT domains. Windows NT 5.0 
uses Kerberos authentication to perform a user’s interactive logon to a Windows NT 
domain account. Public-key extensions to the initial Kerberos authentication provide 
the protocol support for smart card logon to Windows NT 5.0 [3]. The Kerberos proto¬ 
col is implemented as a security provider under the Security Support Provider Interface 
(SSPI). 

The Kerberos security provider is used by the SMB Client and Server and is available 
for DCOM, authenticated RPC, and any application protocol designed to use SSPI for 
network security. SSPI is a Win32 security interface available on Windows NT since the 
3.5 release and is also supported on Windows 95. SSPI is designed using the same 
architectural concepts as the Generic Security Services API (GSS-API, RFC 1964) and 
isolates applications from the details of network security protocols. More information 
on SSPI is available on the Microsoft Developer Network CD. 

Windows NT 5.0 implements a Kerberos Key Distribution Center (KDC) and Active 
Directory as services on the Domain Controller. Any Windows NT 5.0 DC replica has a 
KDC service for availability. The KDC runs as a privileged process along with the 
Active Directory. Both services manage sensitive information, including passwords for 
user accounts. The Active Directory implements multiple-master update and replica¬ 
tion, so creating a new user account, making changes to a user’s group membership, or 
resetting a password can be done at any available DC. Multiple-master update means 
that updates are no longer restricted to the Primary Domain Controller (PDC) with 
Backup Domain Controllers providing read-only copies. Every replica of the Active 
Directory is an updateable copy of the Domain Controller for a domain. 

Clients and servers use Kerberos messages for mutual authentication. The Kerberos 
request carries the Kerberos session ticket and authenticator issued by the KDC to pre¬ 
vent replays of the session ticket. The Kerberos security provider on the client inte¬ 
grates with the Local Security Authority, which provides a Kerberos ticket cache. When 
the client initializes a security context, the Kerberos security provider retrieves a session 
ticket for the target service from the Local Security Authority ticket cache or requests a 
new session ticket from the KDC. The Kerberos request message created by the 
Kerberos security provider conforms to RFC 1964, the GSS Kerb5 Mechanism token 
formats. Clients can authenticate to any service in the domain or trusted realm that 
supports the Generic Security Services (GSS) Kerb5 mechanism. The Kerberos security 
provider can accept a Kerberos request generated by any client system that supports 
RFC 1964 GSS Kerb5 mechanism token formats. 

This level of interoperability provides support for traditional name-based Kerberos 
authentication in a cross-platform network environment. For Windows NT services, 
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Windows NT authorization data in session tickets are essential to support imperson¬ 
ation and access control in the Windows NT distributed security model. 

Kerberos Protocol and Windows NT Authorization 

Windows NT impersonation requires that the Local Security Authority on the server 
have the ability to obtain the user’s SID and list of group membership SIDs for a client 
in a secure manner. These SIDs are issued by a trusted domain authority and are used 
by the Local Security Authority to create an impersonation access token. After connec¬ 
tion setup, a server thread impersonates the client, and the client’s security access token 
is verified against ACLs on objects by the Windows NT kernel. Using NTLM authenti¬ 
cation, the user’s SID and the group’s SIDs are received directly from the server’s DC, 
and any trusted domains, using the Netlogon secure channel. Using the Kerberos proto¬ 
col, user and group SIDs are transmitted in the authorization data of the Kerberos ses¬ 
sion ticket. 

Windows NT uses KDC-supplied authorization data in tickets to provide the list of 
SIDs that identify the user and group membership. The Local Security Authority uses 
the authorization data to support impersonation for the Kerberos security provider. 

The Kerberos protocol permits the use of application-defined authorization data in 
Kerberos tickets. Windows NT use of authorization data is consistent with revisions to 
RFC 1510 submitted to the IETF by Theodore Ts’o of MIT and Cliff Neuman of 
USC/ISI and was reviewed by the authors to minimize interoperability problems. 

The Windows NT KDC adds authorization data to the Ticket Granting Ticket during 
initial domain logon that includes the user’s SID and groups from the account domain. 
Group membership is expanded at initial logon. The Windows NT KDC copies the 
authorization data from the Ticket Granting Ticket into the session tickets used to 
authenticate to target application servers. In a multiple-domain network, the KDC han¬ 
dling the session ticket request for a target server may add additional groups to autho¬ 
rization data to include any groups in the target domain to which the user may belong. 

The format of the Windows NT authorization data is subject to change until the release 
of Windows NT 5.0. Microsoft will publish the format of Windows NT KDC-issued 
authorization data about the same time as the final release. In general, the authoriza¬ 
tion data format will be a list of security identifiers in Network Data Representation 
(NDR) for cross-platform support and contain an integrity signature by the KDC. 

Leveraging Kerberos in Windows NT Networks 

Kerberos authentication is used by many Windows NT domain services. SSPI is used 
for network authentication in most system services and it is fairly straightforward to 
update those services from NTLM to Kerberos with minimal effort. The most complex 
change was to the SMB server, which did not use SSPI prior to Windows NT 5.0. Many 
new distributed services in Windows NT 5.0 use Kerberos authentication. Here is a par¬ 
tial list of how Kerberos authentication is used in Windows NT 5.0: 

■ authentication to the Active Directory using LDAP for queries or directory 
management 

■ CIFS/SMB remote file access protocol 

■ distributed filesystem management and referrals 

■ secure DNS address update 

■ print spooler services 

■ optional IPsec host-host authentication in ISAKMP/Oakley 
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■ reservation requests for network Quality of Service 

■ Intranet authentication to Internet Information server 

■ authentication of public-key certificate requests to the Microsoft Certificate Server 
for domain users and computers 

■ remote server or workstation management using authenticated RPC and DCOM 

In addition to these services, one of the goals of Windows NT 5.0 is the ability to 
turn off NTLM authentication in networks where all machines are running Windows 
NT 5.0. 

Network Security Interoperability 

Windows NT 5.0 domains must be able to support Windows NT 3.X-4.0 workstations 
and servers, Windows 95/98 clients, as well as Windows NT 5.0 desktops and servers. To 
provide that support, Windows NT 5.0 supports NTLM authentication for downlevel 
clients and servers. Microsoft will also provide a Distributed Systems Client upgrade for 
Windows 9x systems with the Windows NT 5.0 release that includes a directory client 
based on LDAP and Kerberos security for authentication. 

Kerberos interoperability testing is ongoing using the MIT Kerb5 1.0 release with avail¬ 
able updates. CyberSafe and other vendors with Kerberos-based products are also car¬ 
rying out independent interoperability testing between UNIX systems and Windows 
NT 5.0. The primary interoperability objective is to allow application clients that use 
Kerberos SSPI or GSS-API on UNIX to authenticate to application servers that also 
support Kerberos authentication. Windows NT 5.0 Betal demonstrates some of that 
interoperability. Additional support for cross-realm trust and full support for UNIX 
application servers is available in the Windows NT 5.0 Beta2 release. These features 
depend on Windows NT 5.0 naming support for Kerberos services and not necessarily 
the Kerberos security protocol itself. 


The question often arises: 
how will Windows NT 5.0 


work with existing UNIX- 
based Kerberos servers? 


NT and UNIX KDC 

The question often arises: how will Windows NT 5.0 work with existing UNIX-based 
Kerberos servers? There are two ways Windows NT can interoperate with MIT 
Kerberos-based KDCs. First, the Windows NT 5.0 workstation can be configured to use 
a UNIX KDC. Users can logon to Windows NT using an account defined in the UNIX 
KDC. This is just like the UNIX workstation support for Kerberos logon. 

Any Windows NT or UNIX application that requires only name-based authentication 
can use a UNIX KDC as the Kerberos server. For example, a database application server 
with its own database authorization table can authenticate Windows NT clients using 
Kerberos tickets issued by a UNIX KDC. Because the database server does not use 
Windows NT access control, the server could also run on Windows NT without using 
impersonation. The application server calls the Kerberos security provider to accept 
session tickets issued by the UNIX KDC and query the security context for the client 
name. The tickets issued by the UNIX KDC can be used for mutual authentication and 
message privacy. However, without authorization data, the security context cannot be 
used for NT impersonation. 

The second way Windows NT interoperates with MIT Kerberos is through cross-realm 
trust between a UNIX realm and Windows NT domain. Cross-realm trust is the best 
way to support Windows NT services that use impersonation and access control. Cross¬ 
realm trust is similar to the widely used Windows NT multiple-domain model of 
account domains and resource domains. In this case, the UNIX KDC acts as an account 
domain, and Windows NT-based services are located in the Windows NT resource 
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domain. The Windows NT KDC is the authorization server for Windows NT-based ser¬ 
vices. Windows NT authorization data are added by the Windows NT KDC to session 
tickets for target servers in the Windows NT domain. The authorization data are based 
on name mapping between principals in the UNIX realm and shadow or proxy user 
accounts and their group membership in the Windows NT Active Directory. These 
accounts in the Active Directory can be synchronized and managed remotely using 
LDAP. 

Can the UNIX KDC be the authorization server for Windows NT services? The 
Windows NT distributed security model depends on more than a list of SIDs for 
authorization data in Kerberos tickets. For example, the ACL editor used to manage 
security on NTFS files requires a domain server for SID-to-name lookup that uses RPC 
over the Netlogon secure channel to the DC. Without the RPC interface to translate 
identifiers, the ACL editor displays all NTFS file access rights granted to “<Account 
Unknown>” for SIDs that cannot be resolved. 

Another requirement is support for the user interface to select accounts to grant access 
rights. This dialog allows the administrator to select a user or group from a list of 
accounts. The account list results from an LDAP query to the Active Directory and 
translates the account names to SIDs when building ACL entries. 

A third requirement is support for NetBIOS naming by the KDC. Windows NT users 
are familiar with NetBIOS computer names, and applications must be able to authenti¬ 
cate to servers using names like \\projectl\projectshare. Finally, the Kerberos security 
provider verifies authorization data in Kerberos tickets presented by untrusted applica¬ 
tions using a secure RPC to the domain controller. The secure RPC is used to verify the 
KDC signature to prevent unauthorized use of group membership privileges. 

To replace the domain controller with a UNIX KDC would require enhancing the cur¬ 
rent MIT Kerberos implementation with support for the Netlogon secure channel, 
authenticated RPC, NetBIOS naming support, and the LDAP protocol. These protocols 
go well beyond the authentication services provided by the MIT Kerberos server. 

Conclusion 

Microsoft is working hard at providing interoperable cross-platform network security 
using industry standard protocols such as SSL, Transport Layer Security, 
ISAKMP/Oakley for IP security, and Kerberos Version 5. Windows NT 5.0 demon¬ 
strates that commitment to interoperability and opens new opportunities for secure 
distributed computing in heterogeneous enterprise networks. Managing the security 
infrastructure in large-scale enterprise networks requires multiple protocols to support 
a distributed security model. Active Directory and Kerberos Version 5 authentication 
are important parts of the Distributed Systems infrastructure in Windows NT 5.0. 

Notes 

[1 ] “The Kerberos Network Authentication Service (V5),” J. Kohl and C. Neuman, 
Internet RFC 1510, September 1993. 

[2] Information on SESAME is available at <http://www.esat.kuleuven.ac.be/cosic/sesame/ 
doc-txt.html>. 

[3] Windows NT 5.0 implements the current draft of the IETF CAT draft for PKINIT 
except that the protocol draft requires encryption of an arbitrary protocol element 
using a 512-bit RSA public key, which an exportable product such as Windows NT can¬ 
not fully comply with. Windows NT uses the PKCS #7 standard for encrypted data 
instead in this particular instance, and this issue has been discussed with the protocol 
authors. 
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trends in computer 
attacks 

Over the last few years, we have seen a number of different types of attack 
become well known. This has become particularly evident because the Internet 
has recently suffered a number of large-scale attacks, involving thousands of 
computers, using these techniques. Here are descriptions of some of these 
attacks with some simple ways to harden your hosts and networks against 
them. I am assuming you already have taken some minimal security precau¬ 
tions, such as installing the latest patches. 

IP Spoofing 

When the IP protocol was first designed, the Internet was a much friendlier place. 
Authentication of IP packets was not a feature to be added until the development of 
IPSec [1 ] [2] [3]. Even so, it will take many years for IPSec to be deployed and widely 
used. This has brought us to our current chaotic state of affairs. 

IP spoofing is the act of injecting into an IP network packets with a source address 
other than that assigned to the sending host. This “spoofed” address can be unassigned 
or belong to another host. IP spoofing is generally the building block used by other 
network attacks. It allows the attacker to impersonate another host and/or hide his ori¬ 
gin. This has made tracking the source of many network attacks a very painful process 
reminiscent of the way the telephone companies used to track the source of a telephone 
call by tracing the wires in old switches one central office at a time - this was a very 
slow and error-prone process. 

Unfortunately, there is no silver bullet to stop IP spoofing. The best we can do is pro¬ 
tect ourselves against attacks that attempt to spoof our own addresses and stop our net¬ 
work from being the source of such attacks. 
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Preventing Reception of Spoofed Packets 

In a common attack involving IP spoofing and predictable TCP sequence numbers, an 
attacker masquerades as a trusted local host with an IP address in our network to 
obtain access to some other host in our network. We can stop such attacks at our bor¬ 
der routers by configuring them to drop any packets coming into our network with a 
source address belonging to our network. We can also stop packets with known “bad” 
addresses from coming into our network [4]. Bad addresses are 0.0.0.0 (all zeros broad¬ 
cast), 255.255.255.255 (all ones broadcast), 127.0.0.0/8 (loopback), 10.0.0.0/8 
(reserved), 172.16.0.0/12 (reserved), and 192.168.0.0/16 (reserved). 


Preventing Transmission of Spoofed Packets 

To stop our network from becoming the source of such attacks, we must configure our 
border routers to drop any packets exiting our network with a source address not 
belonging to our network. If all networks attached to the Internet applied such filtering 
rules to their routers, we would see an incredible decrease in the number of network 
attacks, and tracking them would be much easier. 

Filtering is not more widespread because it imposes a performance penalty on the 
router that is unacceptable to some network operators. This should be weighed against 
the bad publicity you will generate and possible legal actions that may come about if 
your network is found to be the source of an attack. 
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Internet access providers who route traffic for other networks must take them into 
account when configuring the input and output filters in their routers. For more infor¬ 
mation on IP filtering to stop IP spoofing, see [5]. IP spoofing filters may interfere with 
Mobile IP protocols [6]. Work is currently under way within the IETF to rectify this 
problem. 

Source Routing 

Source routing is a little-used feature of the IP protocol that allows the sender of an IP 
packet to determine the route the packet will travel through the network. When attack¬ 
ers spoof IP packets they do not see the response packets from the target unless the 
attackers are attached to the same broadcast network as the host they are spoofing, or 
they are located somewhere along the route the packets travel back to the spoofed host. 
Source routing allows attackers to route the response packets through a segment to 
which the attackers are attached. They can then see the response to their spoofed pack¬ 
ets and obtain information such as TCP sequence numbers. 

If you are using some type of network analysis tool, such as tcpdump or Network 
Flight Recorder [7], the source route information can be used to trace the source of an 
attack, because the attacker must be attached to one of the networks in the path of the 
route of each packet. No widely used applications or protocols deployed in the Internet 
today use source routing. It is recommended that you disable this feature in all your 
routers and hosts. 

SYN Flooding 

SYN flooding is a network attack that exhausts the resources of the target machine by 
sending it a large number of spoofed TCP connection requests. These requests tie and 
consume memory and data structures in the target machine and may cause legitimate 
connection requests to be denied. This type of attack became popular after two hacker 
publications published articles, together with source code, to demonstrate the problem 
[8]. A large-scale attack against the Internet access provider PANIX and others soon 
ensued [9], 

A number of different solutions have been offered, and as many have been implement¬ 
ed. They include SYN cookies, RST cookies, random early drop, increasing the backlog 
queue, creating new light-weight structures to be used instead of protocol control 
blocks, and using hashes instead of linked lists [10] [11]. Apply the appropriate patch 
or solution from your vendor. 

Smurfing 

Smurfing is an attack that involves spoofing a number of ICMP echo (ping) packets 
with the victim s address as the source address and a directed broadcast address as the 
recipient. A directed broadcast address allows you to address every host on a subnet. By 
carefully selecting a large, densely populated subnet, an attacker can generate enough 
traffic from the subnet hosts responding to the ping packets to consume a lot of net¬ 
work and host resources with a few spoofed packets. 

This type of attack came to the public’s attention when a number of large-scale attacks 
on Internet service providers and IRC servers occurred during December 1997 and 
January 1998 [12]. A similar attack uses the UDP echo service instead of ICMP echo 
packets to generate traffic. This is even more devastating because the target will send 
back ICMP unreachable messages, thus contributing to the traffic [ 13]. It is also possi¬ 
ble, in certain situations, to create loops between the echo and chargen services in the 
relay hosts and the victim host. 
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Very few applications use directed broadcast addresses. Some of these are network 
management and mapping tools and, in some instances, Microsoft’s network browsing 
applications. It is recommended that you disable translation of layer 3 broadcasts into 
layer 2 broadcasts at your router. You can also configure your hosts not to respond to 
broadcast ping packets or to ignore ping packets altogether. You should also disable the 
echo and chargen services. 

For a long discussion on smurfing, see [14]. 

Predictable Initial TCP Sequence Numbers 

This attack allows an attacker to create a one-way TCP session with the target hosts 
while spoofing another host by guessing the TCP sequence number used by the other 
end. This attack was first described by Robert Tappan Morris in 1985 [15] and general¬ 
ized by Steven Bellovin in 1989 [16]. It was made famous by the break-in into Tsutomo 
Shimomura’s computers [17] that led to the hunt for and eventual arrest of Kevin 
Mitnick. [18] This attack is normally aimed at services that trust IP addresses such as 
the r-commands, but can generally be used to impersonate other hosts. In this way, you 
can, for example, send untraceable email. Contact your vendor for a patch if your oper¬ 
ating system is vulnerable. 

Buffer Overflows 

Buffer overflows have become the most common security vulnerability found in UNIX 
operating systems today. They result from the lack of a good string or buffer data type 
in C and the misuse of the standard C library’s string functions. We obviously have 
learned little from history. This is the same attack method the Internet Worm used ten 
years ago (in November) to infect machines via fingerd [19]. 

In the most common attack, an intruder attempts to overflow the buffer of a remote 
daemon or a setuid program to inject his machine code into the program’s address 
space and overwrite the return address of some function. When this function returns, it 
will jump the intruder’s code, which will normally spawn a shell. 

For a long discussion of buffer overflows, see [20]. 

Operating System-Specific Actions 

Here are some actions and commands specific to particular operating systems you can 
use against the attacks described previously. You should take the time to understand the 
negative side effects such changes will have in your environment. 

AIX 


Buffer overflows have 
become the most common 
security vulnerability found 
in UNIX operating systems 
today. 



To prevent AIX from forwarding packets, use the command 
/usr/sbin/no -o ipforwarding=0 
To prevent AIX from forwarding source-routed packets, use the command 
/usr/sbin/no -o nonlocsrcroute=0 
AIX cannot be configured to discard source-routed packets destined for itself. 

To defend against SYN flooding, apply the appropriate patch (or superseding patch) 
from the following list: 

AIX 3.2.5 No APAR available; upgrade to AIX 4.x recommended 
AIX 4.1.X APAR- 1X62476 

AIX 4.2.x APAR - 1X62428 

AIX 4.X ships with response to broadcast pings disabled by default. AIX 3.X cannot be 
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configured to prevent it from responding to broadcast pings. To prevent AIX 4.X from 
responding to broadcast pings, use the command 

no -o bcastping=0 

BSD/OS 

To prevent BSD/OS from forwarding any packets, use the command 

sysctl -w net.inet.ip.forwarding=0 

BSD/OS versions prior to 2.1 ship with source routing enabled by default. Newer ver¬ 
sions ship with source route forwarding disabled by default. To prevent BSD/OS from 
forwarding source routed packets, use the command 

sysctl -w net.inet,ip.forwsrcrt=0 

BSD/OS cannot be configured to discard source-routed packets destined for itself. 

Under BSD 2.1 

To defend against SYN flooding, apply the patch K210-022. This patch adds a SYN 
cache. The are new sysctl entries to tune it’s behavior: 

net. inet. tcp. syn_cache_limit, net. inet. tcp. syn_bucket__limit, and 
net.inet.tcp.syn_cache_interval. 

To enable a check that tries to detect spoofed IP packets, apply the patch K210-021 and 
use the command 

sysctl -w net.inet.ip.sourcecheck=l 

Be careful. This may cause legitimate packets to be dropped if you are in an environ¬ 
ment with asymmetric routing. 

To prevent memory exhaustion by fragment reassembly, apply patch K210-021. This 
limits the number of fragments in the reassembly queue. To tune the limit, use the 
command 

sysctl -w net.inet.ip.maxfragpackets=100 

These patches have been integrated into BSD/OS versions greater than 2.1. 

Cisco 

Assuming that your router connects to your ISP using a serial 0/1 interface, you can 
apply the following access list to attempt to stop some IP-spoofed packets: 

access-list 111 deny ip 0.0.0.0 255.255.255.255 any 
access-list 111 deny ip 255.255.255.255 255.255.255.255 any 
access-list 111 deny ip 10.0.0.0 0.255.255.255 any 
access-list 111 deny ip 172.16.0.0 0.15.255.255 any 
access-list 111 deny ip 192.168.0.0 0.0.255.255 any 
access-list 111 deny ip < your-network-address> < mask> any 
access-list 111 permit ip any any 

interface serial 0/1 
ip access-group 111 in 

Apply the following access-list to stop any spoofed packets from leaving your 
network.: 

access-list 222 permit ip < your-network-address> < mask> any 
access-list 122 deny ip any any log 
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interface serial 0/1 
ip access-group 122 out 

For more information on configuring Cisco access control lists, see [21]. 

Upgrade to IOS 11.1(14)CA or later. This version integrates changes so that packets 
denied by an access list will be dropped at the interrupt level, with the exception of two 
packets per second per access list deny line. This greatly reduces the overhead incurred 
by the access lists. 

To prevent Cisco routers from forwarding source-routed packets, use the command 

no ip source-route 

To prevent Cisco routers from converting layer 3 broadcasts into layer 2 broadcasts and 
becoming an intermediate site in a smurf attack, use the command 

no ip directed-broadcast 

Digital UNIX 

To defend against SYN flooding, increase the listen queue and lower the initial time¬ 
out. These tunable parameters are present in Digital UNIX 3.2G, 4.0,4.0A, or later. 

# dbx -k /vmunix 

dbx> assign sominconn=32767 
dbx> patch sominconn=32767 
dbx> assign tcp_keepinit=30 
dbx> patch tcp_keepinit=30 
dbx> quit 

To fix the predictable TCP sequence numbers, apply one of the following patches: 


Version 

Patch 

V4.0 

OSF400-247 

V4.0A 

OSF405-071 

V4.0B 

OSF410-068 

V4.0C 

OSF415-410068 

FreeBSD 



To prevent FreeBSD from forwarding any packets, use the command 

sysctl -w net.inet.ip.forwarding=0 

FreeBSD ships with source route forwarding disabled by default. To prevent FreeBSD 
from forwarding source-routed packets, use the command 

sysctl -w net.inet.sourceroute=0 

FreeBSD cannot be configured to discard source-routed packets destined for itself. 

FreeBSD versions prior to 2.2.5 cannot be configured to ignore broadcast or multicast 
pings. Newer versions ship with response to broadcast and multicast pings disabled by 
default. To modify this behavior, use the command 

sysctl -w net.inet.icmp.bmcastecho=0 

HP-UX 

To prevent HP-UX from forwarding any packets, use the command 
HP-UX 10.x: 

nettune -s ip_forwarding 0 
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HP-UX 9.x: 


adb -w /hp-ux /dev/kmem 
ipforwarding/W 0 
ipforwarding?W 0 
A D 

HP-UX ships with source route forwarding enabled by default, cannot be configured to 
prevent the forwarding of source-routed packets, and cannot be configured to discard 
source routed packets destined for itself. 

To prevent HP-UX from using predictable sequence numbers, use the command 
HP-UX 10.x: 

nettune -s tcp_random_seq < value> 

HP-UX 9.x: 

echo "tcp_random_seq?W < value>" | adb -w /hp-ux 
where < value> is one of 

0 - old behavior (default) 

1 - rand(3) behavior 

2 - rand48(3) behavior 

The seed value for the rand* () functions is based on the time when tcp__init () (or 
nettune) is called, so don’t make your uptime public (i.e., rstatd). 

To defend against SYN flooding, apply the appropriate patch (or superseding patch) 


from the following list: 

Patch Number 

Release 

Hardware Platform 

PHNE.9525 

9.0 

s800 

PHNE_10864 

9.01 

s700 

PHNE_9100 

9.03,9.05, 9.07 

s700 

PHNE_9101 

9.04 

s800 

PHNE_9102 

10.01 

s700 

PHNE_9103 

10.01 

s800 

PHNE_9104 

10.10 

s700 

PHNE_9105 

10.10 

s800 

PHNE_9106 

10.20 

s700 

PHNE.9107 

10.20 

s800 


After you apply the patch, turn on SYN flooding protection by using the command 

nettune -s hp_syn_j>rotect 1 

See [22] for information on how to tune the so_qlimit_min kernel parameter. 

IRIX 

To defend against SYN flooding, apply the appropriate patch (or superseding patch): 

IRIX 5.3 1529 

IRIX 6.2 1418 
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Linux 


To prevent Linux from forwarding any packets, recompile the kernel with the option 
CONFIG_I P_FORWARD turned off. 

To prevent Linux from forwarding any source-routed packets or accepting any source- 
routed packets destined for itself, recompile the kernel with the option 
config_i p_nosr turned on. 

To defend against SYN flooding, recompile the kernel with the option 
config_syn_cookies or config_rst_cookies turned on. 

To prevent Linux from responding to pings altogether, recompile the kernel with the 
option config_ip_ignore_echo_requests turned on. 

If you are using Linux as a firewall, recompile the kernel with the option 
CONFIG_ip_always_defrag turned on to protect machines behind it from IP frag¬ 
mentation attacks. 

To mark the stack as nonexecutable apply the patch at 

<http://www.false.com/security/linux/secure-linux.tar.gz> and recompile the kernel with the option 
config_secure_stack turned on. 

NetBSD 

To prevent NetBSD from forwarding any packets, use the command 
sysctl -w net.inet.ip.forwarding=0 

NetBSD versions prior to 1.2 cannot be configured to discard source-routed packets. 
Newer versions ship with source route forwarding enabled by default. To prevent 
NetBSD from forwarding source-routed packets use the command 

sysctl -w net.inet.ip.forwsrcrt=0 

NetBSD cannot be configured to discard source-routed packets destined for itself. 

To prevent NetBSD from converting layer 3 broadcasts into layer 2 broadcasts and 
becoming an intermediate site in a smurf attack, use the command 

sysctl -w net.inet.ip.directed-broadcast=0 

OpenBSD 

OpenBSD ships with forwarding disabled by default. To prevent OpenBSD from for¬ 
warding any packets, use the command 
sysctl -w net.inet.ip.forwarding=0 

OpenBSD ships with source route forwarding disabled by default. To prevent OpenBSD 
from forwarding source-routed packets, use the command 

sysctl -w net.inet.dosourceroute=0 

OpenBSD 2.2 and earlier cannot be configured to discard source-routed packets des¬ 
tined for itself. OpenBSD-current discards source-routed packets destined for itself if 
the net. inet. dosourceroute is not set. 

OpenBSD has unpredictable initial TCP sequence numbers. 

Solaris 

To prevent Solaris from forwarding any packets, use the command 

ndd -set /dev/ip ip_forwarding 0 
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Solaris ships with source route forwarding enabled by default. To prevent Solaris from 
forwarding any source-routed packets, use the command 

ndd -set /dev/ip ip_forward_src_routed 0 

Solaris cannot be configured to discard source-routed packets destined for itself. 

To prevent Solaris from using predictable sequence numbers, use the command 

ndd -set /dev/tcp tcp_string_iss < value> 
where < value > is one of 

0 - old behavior 

1 - using random(3) [default] 

2 - RFC 1948 support 

‘O’ is the old predictable algorithm. V used random(3) and may be predictable if the 
attacker knows the time the machine was booted or the time the kernel parameter was 
changed. New in Solaris 2.6/2’ implements the recommendations of RFC 1948. For it 
to work, you must configure a long-term secret on each machine. Sun recommends 
that this secret be encrypted password entry for the root account as it is found in the 
shadow password file. To configure this secret, use the command 

ndd -set /dev/tcp tcp_1948_phrase 

< root's password entry from /etc/shadow > 

Under Solaris 2.6, the correct way to enable unpredictable sequence numbers is to edit 

/etc/default/inetinit and add 

TC P_STRONG_ISS=2 

If you have many machines with the same encrypted root password, you will want to 
find another secret to use for setting tcp_l948_phrase. 

To defend against SYN flooding, tune TCP abort time-out value using the command 

ndd -set /dev/tcp tcp_ip_abort_cinterval 10000 

The value is given in milliseconds, which may make sites over links with high latency 
unreachable or unreliable. You can also increase the size of the backlog queue by using 
the commands 

echo "tcp_param_arr< 14/W 0tl0240" | adb -kw /dev/ksyms /dev/mem 
ndd -set /dev/tcp rcp_conn_req_jnax 8192 

To prevent Solaris from responding to broadcast pings, use the command 

ndd -set /dev/ip ip_respond_to_echo_broadcast 0 

To protect against some buffer overflows and mark the stack as nonexecutable in some 
Sparc architectures, use the script found at 

<http://www.netspace.org/cgi-bin/wa?A2=ind9703B&L=bugtraq&D=&H=&T=&0=&F=&P=1406>. 

If you have any questions, corrections or additions please feel free to reach me at 

<alephl@dfw.net>. 
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Unfortunately, names of large numbers 
are ambiguous. Well use the US conven¬ 
tion for these and also provide an unam¬ 
biguous representation of the number 
where necessary throughout this article. 


of DES keyspace 

"When in doubt, use brute force." - Ken Thompson 

The Data Encryption Standard (DES) has been the workhorse of cryptography 
for some 20 years. Its wide deployment but small (by today’s standards) key 
size make it an interesting target for attackers. This article discusses the first 
public “crack” of a DES-encrypted message using brute force and shows how 
the sort of power necessary to reproduce this can be mustered by individuals 
and very small organizations with little or no funding. We originally suggested 
that this work was repeatable and have been proven correct: DES has fallen 
again, and RC5-32/12/7 has been defeated by brute force. We strongly advise 
systems based on DES to be replaced with systems that use longer keys. 

On January 28, 1997, RSA Laboratories launched a series of cryptographic challenges. [1] 
The goal was to find secret messages that had been encrypted with keys of varying 
length. One of the most tantalizing of these challenges was based on DES, a widely used 
encryption algorithm with a 56-bit key. Soon after two easier challenges had been bro¬ 
ken, attention turned to the DES challenge. 

Led by Rocke Verser, Matt Curtin, and Justin Dolske, the DESCHALL effort (home 
page, <http://www.frii.com/~rcv/deschall.htm>) sought to crack RSA’s DES Challenge by means 
of a large-scale, distributed computing project on the Internet. We simply endeavored 
to try each of the 2 56 (over 72 quadrillion) keys that might have been used to encrypt 
the secret message - a brute force attack. Brute force attacks like this are naturally suit¬ 
ed to distributed or parallel computing efforts, because they essentially consist of a 
large number of independent problems - the testing of each key. 

Although not a new attack by any means, brute force key search has been a metric by 
which the security of cryptosystems has been judged. If an algorithm is believed to be 
“safe,” that typically means that the best known attack against the system is unfeasible. 
Often, a “safe” algorithm’s security is measured in terms of the cost of a brute force 
attack. The number of possible keys determines the feasibility of this attack. 

Although many believe that government intelligence agencies have the technology and 
resources available to efficiently perform brute force attacks against DES, no one had 
ever accomplished the feat in public before this project's success. DES is still widely 
deployed in a variety of environments, including financial circles. DES is, therefore, a 
real target, and because of its relatively small key size (by today’s standards), it’s an 
attractive one. 


Architecture 

Our approach centered around a single “key server” that kept track of which blocks of 
keys had been tested. Clients would then contact the server, via the Internet, to request 
work and report the results, as illustrated in Figure 1. 

All communication between client and server was through the UDP protocol, a stan¬ 
dard part of any IP stack. UDP is a low-overhead, connectionless protocol that was suf¬ 
ficient for our needs. The protocol used is an extension of the one designed and used 
by Germano Caronni in the crack of RSA’s RC5-32/12/6 contest [2]. It consisted of just 
five simple messages types: 
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1. “Initial” request provided the server with the client type/version and 
requested an initial block of keys to check. 

2. “Not found” request reported a range of previously assigned keys that 
were found not to contain the key and requested a new block of keys to 
check. 

3. “Answer” reply was sent by the server in reply to a clients request for 
more work (via either of the above two messages). 

4. “Message” reply could be sent by the server to cause a text message to b( 
displayed by the client, in order to convey important information. 

5. “Kill” reply could be sent by the server to cause a client to terminate. 

Clients would automatically increase the size of the key blocks they Figure 1. DESCHALL Architecture 

requested so they would gradually reach the point where a block of keys 

took about 30 minutes to test. Blocks were always 2 s keys in size, where N was generally 

between 22 and 30. 

Additionally, all messages dealing with key blocks included checksums for message 
integrity, because UDP (as a low-overhead protocol) does not make any such checks 
itself. To help prevent sabotage, the clients “Not found” message contained additional 
data, calculated during its search, to allow the server to verify that the client had actual¬ 
ly searched the assigned keyspace. 

Server and Clients 

For most of the challenge, the key server was an IBM PS/2 Server (a relatively slow 486- 
based system) with 56MB of RAM, connected to the Internet via a dedicated 28.8 kbps 
PPP connection. This server was able to easily handle the load from approximately 
10,000 clients, although a Pentium-based backup server was occasionally used during 
periods of unusually high load. 

The clients that used this protocol were designed to run on a wide variety of systems. 

By the end of the contest, we had 40 different clients available for a variety of different 
hardware and operating system combinations. All clients running on Intel (or compati¬ 
ble) and Macintosh PowerPC hardware contained hand-optimized assembly code, 
while the remainder of the clients were entirely done in C. Java was briefly considered, 
but it was quickly dropped - we already had clients for a large variety of systems, and it 
was generally agreed that the speed of a generic Java version would be unacceptable. 

The clients were highly optimized for decrypting DES messages, using a variety of 
methods to optimize the DES process and detect nonwinning keys as early as possible. 

Using these methods, a 200 MHz Pentium system was able to test approximately 1 mil¬ 
lion keys/second, and a 250 MHz PowerPC 604e-based system reached 1.5 million 
keys/second. Toward the end of the contest, we introduced a “bitslice” client inspired by 
Eli Biham [3] that was extremely fast on 64-bit systems, and slightly faster on most 
other systems. 

With this new client, a 500 MHz Alpha was able to test 5.3 million keys/second, and a 
167 MHz UltraSPARC was able to test 2.4 million keys/second. In the end, Intel-com¬ 
patible systems accounted for 53.8% of the keys searched, SPARC-based systems, for 
21.3 %, PowerPC systems, for 8.1%, and a mix of other systems, for the remaining 
16.8% of the keys. 

All the clients would, by default, run with low priority, so only “idle cycles” would be 
used, rather than interfering with the work the host would normally perform. An inter- 
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esting side effect of the “only use idle cycles” approach of DESCHALL, shown in Figure 
2, is that weekends would show significant peaks in average host speed, because there 
were more idle cycles generally available. Also, performance improvements in the 
clients contributed to a steady increase in average host speed. 

Gateways and Proxies 

Soon after DESCHALL began to become popular, we found that firewalls at 
some sites would block the UDP messages the client and server were trying to 
exchange. To circumvent the problem, we developed a pair of “gateways” or 
“proxies” that would tunnel the UDP messages through TCP connections, 
illustrated in Figure 3. One of these proxies would sit inside the user’s net¬ 
work, and the other was maintained by the DESCHALL organizers. Clients 
running behind a firewall would use the “U2T” gateway as a key server. The 
U2T gateway would receive the client’s datagram and send the data through a 
TCP connection to the “T2U” gateway. The data was also reformatted to simu¬ 
late an HTTP (Web) request, to allow passage through firewalls that disallowed 
arbitrary TCP connections but allowed Web access. For sites with application-layer fire¬ 
walls, the client’s U2T gateway could use the site’s Web proxy, which would forward the 
request to our T2U gateway. Via either method, the T2U gateway would then convert 
the received data back into a UDP datagram and send it to the key server. The source 
code for the DESCHALL gateways is available from 
<http://www.interhack.net/projects/deschall/deschall-u2t>. 

The DESCHALL gateways allowed the participation of a large number of people who 
would otherwise have been unable. For example, the entirety of Sun Microsystems’ 
contribution (ranked fifth in total keys tested) was conducted through the gateways. 


DESCHALL Average host speed (estimated) 



Day (to Midnight, Junl7) 

Figure 2. Estimated Average Host Speed 
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Figure 3. DESCHALL Proxy Architecture 


Problems with Small Keys 

We have demonstrated that a brute force search of DES keyspace is not only 
possible, but is also becoming practical for even modestly funded groups. 
RSA’s prize for the find was US$10,000; it is safe to say that DES is inade¬ 
quate for protecting data of any greater value. 

With the increasing amount of computing power available at lower and 
lower costs, today’s cryptosystems must be able to withstand brute force 
attacks that would have been unthinkable in the relatively recent past. Simply 
put, DES and other small-key cryptosystems are weak and vulnerable to 
attack by groups with even minimal funding. 

What we have done is something that the security community has known to 
be possible for some time. To our knowledge, however, this is the first time 
that a 56-bit key for DES (or any cryptosystem) has been successfully found 
in a brute force search. 

At the same time that the cost of computing is going down, the availability of 
massive computational power is increasing. Given the ubiquity of the 
Internet and the fact that key search is easily parallelizable, it’s relatively easy to harness 
the power of many thousands of computers of all types. 


During the course of the DESCHALL project, more than 78,000 unique IP addresses 
were recorded by the key server as having participated to some extent. We had a peak of 
about 14,000 unique hosts within a single 24-hour period. (We actually mean IP 
addresses, which we assume to be hosts. The actual number is inflated by the number 
of participating hosts whose IP addresses are dynamically allocated and deflated by the 
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number of hosts that participate from behind proxy gateways.) All participants were 
volunteers; a one-time prize of US$4,000 was awarded to the person whose machine 
found the winning key. 

Although we got a relatively large number of hosts to participate, it’s very easy to imag¬ 
ine involving a much larger number of hosts. Three major considerations influenced 
the number of hosts available: 

1. Because of concern about government restrictions on the export of cryptographic 
products from the US, our client distribution site would allow only hosts within the 
US or Canada to download our clients. This kept many of our friends abroad from 
participating. 

2. Everyone downloading and installing our client had to go get it, know what it did, 
and usually put forth some effort to keep it running. Spending time to make the 
client a neater “package,” automatically making it start at system boot time, or imple¬ 
menting it as a screen saver might have allowed more of the hosts that participated 
only briefly (i.e., until the system was rebooted) to remain active in the effort 
through its duration. 

If we had been interested in accomplishing our objective without regard to ethical 
considerations, we could have built our client's functionality into viruses, worms, tro¬ 
jan horses, ActiveX controls, and other pieces of software that would do our bidding 
less conspicuously, likely even without the knowledge of the machine’s owner. 

3. The project ran for a relatively brief time: about three months. During this time, our 
effort gained in participating hosts and computing power. If we had required more 
time, the number of participating hosts would have been greater. At some point, we 
would certainly have “topped out,” but that point was nowhere in sight at the time 
we found the key. 

Often, when performing risk analysis, one will consider a threat model in terms of 
varying degrees of an attacker’s resources (“rogue individual,” “moderate,” “well- 
equipped,” etc.). 

The dropping cost of computing technology and the easy access to large numbers of 
machines tend to blur the distinctions among the classifications. Now, individuals and 
small groups can muster the resources equivalent to several large organizations. Data 
once considered vulnerable only to an attack by a “large, well-equipped organization” 
may now be vulnerable to just a few people with friends on the Internet and no budget. 
This ability may especially affect policies that assume a feasible attack on DES would 
require an investment in specialized hardware. 


Data once considered 
vulnerable only to an 
attack by a "large, well- 
equipped organization" 
may now be vulnerable to 
just a few people with 
friends on the Internet and 
no budget. 



Inefficiency of Software Key Searches 

The ease of development and deployment of a software-based system has its trade-off 
in the amount of computational power necessary to accomplish a given task. Hardware 
implementations are always much faster and more efficient than their software 
counterparts. 

Rocke Verser <http:www.frii.com/-rcv/deschall.htm> estimates that a 10,000-cell FPGA 
should be able to process nearly 100 million keys per second. 

Michael Wiener presented a design for a DES key search machine [4]. A $1,000,000 ver¬ 
sion of the machine would be capable of finding DES keys in 3.5 hours, on average. A 
late 1997 version of this machine [5] would be capable of finding DES keys in 35 min¬ 
utes, on average. A $10,000 version of this machine would be capable of finding DES 
keys in 2.5 days, on average. 


May 1998 ;login: 


57 


FEATURES 







# of Hosts Trillions of Keys Trillions of Keys 


58 


A dedicated, funded attacker is going to use more efficient methods of key search than 
idle cycles of general-purpose computers. However, a hardware-based attack requires a 
substantial investment in the hardware. Even though a software-based attack like 
DESCHALL is inefficient in comparison, we were able, at essentially no cost, to take 
advantage of the huge numbers of general-purpose computers already deployed. 


DESCHALL Keys per day 



Marl 5 Mar29 Apr12 Apr26 May10May24 Jun07 Jun21 
Day (to Midnight. Junl7) 

Figure 4. Keys Searched per Day 

DESCHALL Total Keys 



Marl 5 Mar29 Apr12 Apr26 May10May24 Jun07 Jun21 
Day (to Midnight, Junl7) 

Figure 5. Participating Hosts per Day 

DESCHALL Hosts per day 



Scalability 

DESCHALL’s relatively simple architecture was able to accomplish a tremen¬ 
dous amount of work. On our peak day, we sustained a search rate of just 
under seven billion (10 g ) keys per second. On that day alone, more than 600 
trillion (10 12 ) keys were searched. Figure 4 shows our search rate, in keys per 
day, from mid-March until we found the key in mid-June. 

Much of the work accomplished was due to the number of hosts participating. 
As shown in Figure 5, fewer than 1,000 hosts per day were involved in early 
April, and nearly 14,000 per day ran the client at the peak. 

Figure 6 shows that our progress over the course of the project was steady and 
that the architecture we had in place was adequate to meet the demands made 
of it. 

Although we had additional key server capacity available should a need sud¬ 
denly arise, it turned out to be unnecessary. Elaborate systems, including such 
things as hierarchical key servers, turned out to end up either unimplemented 
or problematic in starting and maintaining. We found it best to plan to scale 
the system as high as it could go without requiring additional components but 
to have those additional components ready, just in case of an unexpected 
increase in system load. 

Conclusions 

Three conclusions can be drawn from DESCHALL: 

1. Small-key cryptosystems do not provide adequate security against any but 
the most trivial of attacks. 

2. Whereas previous attacks against “live targets” - cryptosystems enjoying 
“real” use - required the attacker to be relatively well funded, the kind of 
power necessary to attack real targets is becoming available to those who are 
not well funded, but dedicated enough to make an investment of their time. 

3. The potential for performing very large computations without the use of 
expensive, dedicated hardware, or supercomputers can be seen. Over 7.2 
quintillion (10' 8 ) instructions were executed. Succinctly, massive Internet 
computing power is here. 


Day (to Midnight, Junl7) 

Figure 6. Total Keys Searched 


Although DESCHALL was hardly the first distributed Internet computing pro¬ 
ject, we believe it was the largest such project to date, demonstrating how large 
amounts of Internet-accessible computing resources can be mobilized relatively 
easily. This form of computing will probably become more commonplace than it is 
today as more people become involved on a regular basis. Some other large-scale dis¬ 
tributed computing projects are now under way, including RSA’s 64-bit RC5 Challenge 
(<http://www.distributed.net/rc5/>, <http://www.rsa.com/rsalabs/97challenge/>), RSA’s “DES 
Challenge II” (<http://www.rsa.com/rsalabs/des2>, </http://www.distributed.net/des/>), The RSA 
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Factoring Challenge (<http://www.rsa.com/rsalabs/html/factoring.html>), and the Great Internet 
Mersenne Prime Search (<http://www.mersenne.org/>. 

Although using this type of effort to do a brute force attack on a 64-bit key would be 
difficult today, it will certainly be possible in the not so distant future as more people 
become involved in these efforts and as CPU speeds increase according to Moore’s Law. 
At the same time, attacks on smaller key lengths will become easier and easier. 

Although current distributed projects, like DESCHALL, have not been a direct threat to 
computer security (i.e., we didn’t decipher actual, sensitive data), there is no reason that 
a DESCHALL-type project could not be assembled by the “underworld” of computer 
crackers for their own use. 

We hope those responsible for deployment and management of cryptosystems take 
heed to the warnings here and demand strong cryptography with large keys. 
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Apache authentication 
module 

After more than four years of widespread Web-based application development, 
the advantages of the technology are well known. Installation of a Web browser 
can provide an immediate and fairly uniform interface to a wide range of server- 
based applications and documents. The result is that anyone with a Web brows¬ 
er and access to Web servers can obtain business and scientific data from data¬ 
bases, documents, chemical instrumentation, network hardware, vending 
machines, or anything else that can communicate with a Web server. 

In the early days, demonstrations showed how simply these data could be viewed with 
no special software or training. The question often asked, however, was, “If it is so easy 
to get this information, how are we protecting it from access by unauthorized users?” 
Another problem is user authentication for data input applications, a common require¬ 
ment in the pharmaceutical and other regulated industries. 

Standard Web authentication mechanisms were not acceptable for several reasons. They 
required “yet another password” and administrative overhead to manage usernames 
and passwords. From a security standpoint, the more serious problem is that standard 
Web browsers retain username/password combinations and transparently supply them 
to the server whenever needed. Anyone walking up to the browser session could assume 
the identity of the authenticated user and have access to private data. 

Several years ago my first attempt to solve these problems consisted of authentication 
code built directly into specific CGI applications. The authentication methods were 
either the UNIX password or a SecurlD (Security Dynamics, Bedford, MA) passcode. 
Although this solved a number of immediate problems, the limitations were significant. 
Users had to supply a password every time it was required, and accounts local to the 
Web server were required. For a global corporation with many divisions, this presents a 
significant administrative problem. 

The AuthMPTO System 

These problems were addressed by developing the Multi-Password/Time-Out 
Authentication system. The benefits of the system include elimination of separate Web 
password administration, a time-out mechanism, and a cookie containing the users 
name, authentication method, and time of authentication. 

The MPTO system consists of an Apache Web server (<www.apache.org>) module that 
runs under mod_j?erl (Perl embedded in the Web server software), a support module, 
and several database files. As implemented at our site, five different authentication 
mechanisms are available: (1) UNIX passwords for two NIS domains, (2) NT domain 
passwords for two domains, (3) VAX/VMS passwords, (4) SecurlD, and (5) standard 
Web authentication. Users at sites in the US and Europe are currently supported by one 
or more of these authentication methods. To support additional sites without resorting 
to “standard Web passwords,” Novell LAN password authentication will be added to the 
authentication mechanisms. 


How It Works 

The server administrator configures Apache to require authentication for a particular 
directory tree in a manner very similar to the standard method, except that mod_j)erls 
PerlSetVar is used in the access.conf file to set a number of parameters. When a user 
attempts to access documents or applications within a protected directory, an http 
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redirect is used to present the login form. The user selects the authentication method 
he or she wishes to use, then enters the username and password. When the form is sub¬ 
mitted, the username and password are checked against the selected authentication 
mechanism. If the check is successful, a cookie string containing the time of authentica¬ 
tion, username, authentication method, and client IP address is generated. A copy of 
this cookie is stored as a key in a dbm file on the Web server for future reference, and a 
“successful login” page is sent to the user s browser along with the cookie string. A URL 
labelled “Continue” at the bottom of the page will take the user to the originally 
requested page. 

Each time the user attempts to access a secure page, the AuthMPTO cookie string is 
returned to the server and verified against the dbm file. Verification includes time and 
client IP address (to prevent spoofing). Our default setup allows access to secure items 
for up to 15 minutes following the most recent access of a secure item. When 60 min¬ 
utes from the original authentication time have elapsed, the user is required to reau¬ 
thenticate. This 15/60 minute time-out provides reasonable protection if the user walks 
away from an authenticated Web browser. The most recent access of secure items is 
tracked using the data portion of the dbm record. 

Group Authorization 

AuthMPTO provides a group authorization method. A single dbm file on the Web 
server uses keys of the form “usernane@auth_method” with a list of the groups the 
user belongs to as the data. If users attempt to access an item restricted to groups they 
do not belong to, access is refused, and a diagnostic page listing the group(s) allowed to 
access the item is displayed. 

Several methods of automatically administering the group database are currently being 
considered. One is to use department codes from existing company databases along 
with supplemental files because department codes are unlikely to describe all possible 
combinations of group membership. 

Authentication Methods 

NIS authentication makes use of the Perl Net::NIS module by Rik Harris to retrieve the 
encrypted password that is checked using crypt by the standard Perl method. 

VAX/VMS authentication uses the Comm.pl Perl library written by Eric Arnold and 
does an “expect-like” conversation to actually log into a VMS system as a password 
check. 

An early test version of NT domain authentication used smbclient (by Andrew 
Tridgell and the Samba Team) to do a test connection to an NT fileserver. That method 
suffered from a number of problems including putting the password on the command 
line, and required special care if guest logins were allowed on the fileserver. The current 
version uses a small stand-alone program written in C that uses smblib by Richard 
Sharpe. This program requires the following on standard input: a list of NT domain 
controllers, username, and password. The program returns the shell standard 0 for suc¬ 
cess, 1 for failure. 

Use of Authorization Cookies 

In addition to providing the basic authorization token, the MPTO cookie data can be 
easily used by Web applications. An example is to use the username, and possibly the 
authentication method, to fill in noneditable fields of a data entry form as a type of 
electronic signature. In this example, the final entry of data into the database would 
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use the cookie data to obtain a fresh copy of the username to prevent HTML form 
spoofing. 

Configuration and Security Issues 

AuthMPTO is designed for use in a controlled corporate environment. The Apache 
Web server is configured to run as the user “www” which owns the cookie dbm file. 
Care must be taken to restrict access to the Web servers in general, and especially access 
to the cgi-bin directories. A rogue cgi-bin script could place cookie records in the dbm 
file because, by default, all cgi programs run as the user www. 

After further testing, the availability of AuthMPTO will be announced through the 
Apache Module Registry at <www.apache.org>. 
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smart cards 

Introduction 

“This is the year smart cards take off.” We’ve been hearing this for more than 
five years. Are smart cards like monorails - always in the future - or will they 
break out of their cloaked-in-secrecy backwaters and become another ubiqui¬ 
tous computing platform? 


The initial application of smart cards was to add a second factor to credit and debit 
card authentication. Merely having the cardholder enter a PIN to activate the card 
reduced fraud by an order of magnitude and more than paid for the card and the infra¬ 
structure needed to support it. The use of the card as a portable data store with active 
and programmable security has since been extended to a host of loyalty, ticketing, net¬ 
work identity, expense accounting, personal preference, physical access, and electronic 
commerce applications. Today’s off-the-shelf smart cards can generate and store sym¬ 
metric and asymmetric keys, do cryptographic calculations, and be programmed in 
high-level languages. A smart card is an easy-to-carry, tamper-resistant computer with¬ 
out peripherals that has been largely overlooked as a general-purpose computing and 
application-delivery platform. 

Smart Card Hardware 

Smart cards were invented in 1967 by two German engineers, Jurgen Dethloff and 
Helmut Grottrupp. Initial smart card chips were custom ICs, primarily memory-only 
devices, but as the need for general-purpose programmability emerged, the industry 
converted to smart card versions of commodity 8-bit microcontroller cores (e.g., the 
Motorola 6805, the Intel 8051, the Texas Instruments 370, and the Hitachi H8). Single¬ 
chip smart card processors based on these cores are made by almost all the large silicon 
foundries, including Siemens, Philips, Motorola, Texas Instruments, Hitachi, Toshiba, 
and SGS Thomson. 
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Eight-bit microcontroller cores have been popular because of their low price, reliability, 
and suitability for the task at hand. In addition to an 8-bit microcontroller, a middle- 
of-the-road smart card chip will contain 256 bytes of RAM, 8K bytes of nonvolatile 
memory (typically EEPROM), and 20K bytes of ROM. The real estate ratio for these 
three kinds of memory is roughly 1:4:8, so with a fixed die-size - 25 sq mm is the cur¬ 
rent maximum - many alternative memory configurations are available on the market. 
Furthermore, with the emerging need to do “bignum” cryptographic calculations, most 
manufacturers are offering chips with modular arithmetic co-processors that can both 
generate and compute with large cryptographic keys. 

Smart card chips are used as capacity fillers on aging fab lines and as late-life kickers for 
proven, if dated, chip designs. Smart card chip design innovation has concentrated on 
security features rather than on more familiar speed, functionality, and capacity fea¬ 
tures. Hardware properties of smart card chips that contribute to their tamper resis¬ 
tance include non-linear memory layout, scrambled runs, dummy circuits, passivation 
layers, temperature, clock and voltage out-of-bounds sensors, fused test circuits, address 
lock-outs, and EEPROM bulk-erase detection. 

The recent reconceptualization of the smart card as a general-purpose computing plat¬ 
form rather than as simply a secure counter keeper has caused some smart card chip 
manufacturers to put the smart card chip on a more classical processor evolution tra¬ 
jectory. One can expect to see smart card chips in experimental quantities with 32-bit 
processors, unified memory systems, memory management features, and full-duplex 
communication in the next 12 to 18 months. Multiple-chip smart cards are also being 
considered once again. 

A smart card reader is necessary to do anything useful with a smart card. The inclusion 
of smart card support in the next releases of Windows will encourage the provision of a 
smart card reader as standard equipment on Wintel computers. Reader drivers for 
UNIX are harder to come by. A serial port smart card reader that can be used on any 
computer system retails for about $50. Smart card readers are being built into modems, 
keyboards, PCM/GSM cellular telephones, and WebTVs. A smart card industry specifi¬ 
cation for an operating system infrastructure for smart cards called PC/SC is available 
at <www.smartcardsys.com>. 

The Smart Card Marketplace 

For the last 30 years, smart card technology has at least to some extent been deliberately 
held off the general computer marketplace by European governments because of their 
“security through obscurity” security policies. While smart cards delivered stunning 
cost savings and fraud reductions to European telephone and banking systems, the 
restricted access to information and development tools kept them off the screens of 
free-market information technology businesses. One of the greatest, if irrational, fears 
of the smart card industry is that rogue cards which will erode the publics faith in the 
security (not to say sanctity) of the card will be created. Better to constrain the market 
to a small club of proven good guys than to open it up and have to deal with a loose 
cannon. Ross Anderson, among others, has noted that this policy could be interpreted 
as a tacit admission of weaknesses in existing systems and probably does more than the 
occasional hacker incident to slow the growth of trust in smart cards. 

But just as the needs of the Web opened up public discussion of cryptography, so they 
also cause light to be shined into the secret corners of smart card technology. 
Furthermore, to develop a business case against magnetic stripe and high-capacity 
memory cards on one side and personal data devices such as pagers, cell phones, PDAs, 
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A smart card is a cheap, 
portable, tamper-resistant 
store of information with a 
modest, secure computing 
capability. 


and palm computers on the other, the smart card would have had to become a multi¬ 
application platform with lots of available applications. This was not going to happen if 
the worlds smart card programmers were locked in the basements of the smart card 
manufacturers and innovation was paced by government bureaucracies. 

A smart card is a cheap, portable, tamper-resistant store of information with a modest, 
secure computing capability. Unlike a memory card, it can compute in private, and 
unlike a cell phone, you can carry five or six of them in your wallet or purse and even 
afford to lose one occasionally. We don’t know whether the smart card’s design point 
represents a viable and stable long-run computing platform plateau, whether its trade¬ 
off of features is taken up by the public at large, or whether its balance of requirements 
serves anything more than a niche of special applications. The designers of distributed 
computing systems have their work cut out for them as they push the network off the 
desktop and onto the street, and the smart card is at least as street-wise as its technolo¬ 
gy competitors. 

Smart Card Software 

It is useful to differentiate between software written to use a smart card (reader-side) 
and software written to run on a smart card (card-side). Both kinds of smart card soft¬ 
ware share a common attitude, however: by default, trust nobody. Much of smart card 
programming has to do with making sure the other party is who it claims to be and 
convincing the other party that you are who you claim to be. Beyond the management 
of bona fides, the actual data processing done by a smart card is relatively mundane. 

Reader-side software integrates the capabilities of off-the-shelf and standards-conform- 
ing smart cards into larger distributed systems. Besides slightly more elaborate hand¬ 
shake and message protocols, dealing with a smart card is little different from the host 
side than dealing with any other network node. Card communication is master/slave so 
that a remote procedure call metaphor is a useful and familiar computational model for 
reader-side smart card programming. Things can get a little more interesting if one is 
dealing with multiple cards simultaneously and mediating card-to-card transactions, 
but this is actually little different than database-to-database traffic. 

Card-side programming is a completely different kettle of fish and a strange world for 
programmers raised on computational resources whose measurements all start with 
“mega.” 

Perhaps the most challenging constraint is the limited amount of RAM - 128 bytes in 
low-end chips to 762 bytes in high-end chips. Years of training about information hid¬ 
ing and carefully taught aversions to aliasing have to be overcome to squeeze the last bit 
of functionality out of the chip while making sure that your volatiles aren’t smashed by 
a routine you call or a routine it calls. The EQUIVALENCE and COMMON constructs 
of Fortran are alive and well in dealing with RAM in card-side software. Fortunately, 
the compilers and assemblers used in card-side programming offer considerable help in 
efficiently managing the RAM resource. 

Other features of card-side programming that are unfamiliar to the point-and-click 
programmer are the facts that it takes a noticeable amount of time (3 to 10 ms) to 
write to nonvolatile memory, that smart card memory wears out (after 10,000 to 
100,000 writes), and that power can be removed at any moment. This latter phenome¬ 
non is called tearing, and it happens when the cardholder removes the card from its 
life-support at the exact moment your program started to update the contents of the 
electronic purse. Interestingly, the state of the memory may be something completely 
different than the value either before or after your update when next your program 
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runs, and you may discover that values you weren’t updating have also changed. With 
regards to memory write time, keep in mind that your user is standing in the rain at an 
ATM machine or trying to check out during the Saturday morning rush at the grocery 
store. There is little patience available to wait for your program to inherit the banking 
system object. 

Card-side software must be constructed to strengthen and enhance the overall security 
story of the smart card. This means programming to explicitly exclude certain behavior 
while explicitly enabling other behavior. Making sure a program does not do something 
turns out to be at least as difficult as ensuring it does do something else. Testing for the 
absence of a capability, for example, requires a different approach than testing for its 
presence. 

Finally, those features of a smart card that make it tamper-resistant are exactly what 
have historically made it difficult to program; a hacker and a card-side program devel¬ 
oper look an awfully lot alike to both the smart card and to the smart card industry. In 
1996, MAOSCO and Schlumberger radically altered the card-side programming land¬ 
scape by launching smart cards for which card-side software could be written in C and 
a Java dialect, respectively, and run in a secure multiapplication environment on the 
card. 

Summary 

Several marketplace forces are at work to open the smart card as a general-purpose 
computing platform. There are also forces at work to keep it closed and proprietary. 
Information is becoming more accessible, and it is now possible to seriously consider a 
smart card as a component in a distributed computing system. Books on smart card 
hardware, smart card software, and smart card business opportunities are availalble. 
Smart Card Developer's Kit , not incidentally by Tim Jurgensen and me, includes a smart 
card that can be used to familiarize yourself with this unique little pocket computer. 
More information is available at <www.scdk.com>. 
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risk management 
using threshold RSA 
cryptosystems 

A certification authority (CA) in a public-key infrastructure provides the trust 
mechanism through digital signature generation to create users' public-key cer¬ 
tificates. Because the whole public-key infrastructure is based on the security 
of the CA, security mechanisms must be used to manage the risk of the CA. 

One method of managing risk is by distributing trust to multiple parties so that no sin¬ 
gle entity can compromise the system. In fact, the distributed root certification key for 
MasterCard/VISAs Secure Electronic Transaction (SET) root uses threshold cryptogra¬ 
phy mechanisms. Such distributed trust mechanisms can provide enhanced security 
protection against internal collusions as well as external attacks by eliminating the cen¬ 
tralized control; forcing the adversary to take more risks (and to pay more) because it 
must penetrate several systems rather than just one (and in proactive systems it is also 
limited to doing it in a small period of time). 

The SET CA is not controlled by one business entity, but rather by multiple corporate 
entities. The threshold RSA cryptosystem mechanisms can provide for a cryptographic 
tool that establishes a form of risk sharing among multiple entities, each with its own 
security policy. That is, threshold cryptosystems can be set up so that nonrepudiation is 
shared under a single signature. The extent to which the signature generation is shared 
is defined by the access structure the corporate entities have agreed upon. 

Recently, there has been a thrust to construct more efficient protocols for specific prob¬ 
lems, particularly those involving the distributed application of cryptographic func¬ 
tions (surveyed in an invited paper “A New Directions in Cryptography: Twenty 
Something Years After,” by S. Goldwasser in Symposium on Foundations of Computer 
Science (FOCS) ‘97.). Here we focus on what has recently been achieved with efficient 
threshold RSA cryptosystems because RSA is the most commonly used digital signature 
algorithm today. Though we primarily discuss the RSA algorithm, similar results are 
possible with other cryptographic algorithms. A more complete survey by Frankel and 
Yung “Distributed Public Key Cryptosystems,” will be published in the Proceedings of 
Public Key Cryptography (PKC) ‘98. 

Sharing a Secret Key 

I hreshold schemes are the traditional cryptographic example of how to securely and 
reliably distribute a key. With a (t,v)-threshold scheme, a secret value is shared via v 
shadows such that less than a quorum (i.e., at least t) of shadows does not reveal the 
secret value. During a secret reconstruction phase, any quorum of shadows may be 
used to efficiently reconstruct the secret value; however, anyone possessing less than a 
quorum of shadows learns nothing about the secret key. Threshold structures (i.e., any 
set of t out of v) are not the only possible access structures that have been investigated. 

Distributed Function Application 

Threshold schemes are defined as a onetime application. Once the secret is regenerated 
it is known by some entity. Threshold schemes can be used as a building block for dis¬ 
tributing cryptographic functions such as a digital signature. 

Our focus is on systems in which a secret function (e.g., an RSA signature function 
keyed with the CAs private key) is shared among a group of servers. In essence, a 
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(t,v)-secure distributed function application protocol shares a keyed cryptographic 
function f(k,.), where f is a public algorithm and k is a secret key, such that only t or 
more of v servers can apply the function f(k,.) on an input m to obtain f(k,m). For 
security, a subset of smaller subsets cannot evaluate the function on input m. 

An important property that we desire in distributed trust mechanisms is transparency. 
A secure function application protocol is transparent if its input specification providing 
the point of evaluation and output specification providing the function’s output is 
independent of the protocols access structure. Transparency implies that the external 
network providing the input/output to the protocol can use the distributed trust mech¬ 
anism without knowing its inner workings or even which computers provide this ser¬ 
vice, thus providing a transparent service. 

In the certification authority example discussed in the introduction, the function f is 
the signature algorithm, such as RSA, and the secret k is the private key of the certifica¬ 
tion authority. The transparency property allows the verifiers of certificates to be 
unaware whether the certificate was generated using only one certification agent or was 
created with multiple servers. This allows for any generic digital signature verification 
software to work independent of how many servers were used to generate the digital 
signature (certificate). 

Based on secret sharing schemes and tamper-proof devices, one can develop a secure 
function evaluation system. A tamper-proof device is a computational device whose 
state and memory contents are private even to its owner. Hence, the owner gets only 
input/output access to the device. To build a secure function evaluation system, one 
encloses the algorithm in the tamper-proof device. To perform function application, a 
quorum of shareholders transmits their share to the device, and the device computes 
the secret key k. The device can perform function application on function f(k,.) for any 
input m. Only the tamper-proof device learns the key in this process. 

The main concern of this tamper-proof-based system is that it relies on a single trusted 
entity, the tamper-proof device. Because tamper-proof devices do not really exist (and 
are generally called tamper-resistant), this approach may be unacceptable in some 
cases, depending on whether one believes these protection mechanisms are sufficient to 
manage the risk based on the liability that may be incurred due to compromise of the 
hardware device. 


Based on secret sharing 
schemes and tamper-proof 
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secure function evaluation 
system. 



Non-Hardware-Based Solutions 

General compiler protocols provide for the evaluation of a circuit (similarly, function) 
in a distributed manner such that each party in the computation learns nothing more 
than the output and its own secret components of the function’s input. These protocols 
securely compute any public function on secure inputs. The primary difficulty with 
general compiler protocols is that such systems are ordinarily inefficient with respect to 
communication complexity due to their general nature of being applicable to any cir¬ 
cuit or arithmetic operations. However, they constitute a “plausibility result” for many 
tasks. (For a survey of results until 1993 see the doctoral thesis “Complexity and 
Security of Distributed Protocols” at Columbia University, available at 
<http://www.cs.columbia.edu/home/phd_prog/alumni.html>). 

Threshold cryptography, also called function sharing, takes the less general approach; 
however, efficiency has been greatly reduced. Whereas the communication complexity 
of the secure function evaluation depends linearly on the actual size of the circuit com¬ 
puting the cryptographic functions, the communication complexity of function sharing 
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is independent of the circuit size (and is typically a polynomial in the input/output size 
and the number of participants). This difference is crucial to practitioners because the 
communication latency cannot compete with increases in processor speeds. 

The first threshold RSA cryptosystems were based on (v,v)-secret sharing in “Digital 
Multisignatures” (the IMA Conference on Cryptography and Coding by C. Boyd) and 
in “A Practical Protocol for Large Group Oriented Networks” (Eurocrypt l 89 by Y. 
Frankel). Though these schemes can be converted into (t,v)-threshold RSA schemes, 
they become inefficient for some parameters (e.g., grow exponentially for v/2 out of v 
schemes). For small v, however, these systems are very efficient and provide a practical 
solution to distribute an RSA certification. 

Proactive Security 

The notion of “proactive security” (against a mobile adversary) provides enhanced pro¬ 
tection of memories of long-lived cryptographic keys that may be distributed (i.e., pro¬ 
tected by “space diffusion”). Proactive security adds protection by “time diffusion” as 
well. Namely, given a distributed function via threshold cryptography (function shar¬ 
ing) as described, it adds a periodic refreshing of the contents of the distributed servers’ 
memories. This refreshing is a t-wise rerandomization of the local servers’ values in a 
way that preserves the global key but makes previous contents of any set of less than t 
out of the v servers “useless.” 

Proactive security renders useless the knowledge of the mobile adversary (e.g., hackers, 
viruses, bad administrators, etc.) obtained in the past from compromising less than the 
allowed t servers and gives the system a self-securing nature. Proactive security is an 
important risk management tool, especially in environments such as a CA, where a 
long-term public key must be maintained. With proactive security, the shares are 
updated, so a mobile adversary has to act quickly before the next update, although the 
public key is not modified during each rerandomization process. 

Proactive RSA was first solved in “Proactive RSA” in Crypto ‘97 by Y. Frankel, P. 

Gemmel, P. MacKenzie, and M. Yung. The same authors recently developed the first 
optimal resilience (up to a majority of arbitrarily misbehaving servers can “control” the 
computation) proactive RSA threshold cryptosystem, “Optimal Resilience Proactive 
Public-Key Cryptosystems” in the Symposium on Foundations of Computer Science 
(FOCS) l 97. That is, optimal resilience achieves v >= 2(t - 1) + 1. 

Secure Key Generation 

Another important step regarding distributed cryptographic functions is the (efficient¬ 
ly) distributed generation of the function (the key shares). For cryptographic functions 
based on modular exponentiation over a field (whose inverse is the discrete logarithm, 
which is assumed to be a one-way function), a protocol for the distributed generating 
keys was known for quite a while. However, for the RSA function, which requires the 
generation of a product of two primes and an inverse of a public exponent, this step 
was an open problem for many years. A major step forward was recently achieved in D. 
Boneh and M. Franklin, “Efficient Generation of Shared RSA Keys” in Crypto ‘97 by 
Boneh and Franklin (see <http://theory.stanford.edu/-dabo/publications.html>). They showed 
how a set of participants can generate an RSA function efficiently. 

Boneh et al. developed many important new protocol techniques and showed that their 
protocol was secure in the limited model of “trusted but curious” parties. They left 
open the issue of robustness, i.e., generation in the presence of misbehaving (mali¬ 
cious) parties (whereas the Boneh-Franklin protocol may be prevented from ever gen- 
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erating a shared RSA key by such behavior). Recently, robust efficient distributed RSA 
key generation was developed by Y. Frankel, P. MacKenzie, and M. Yung in “Robust 
Efficient Distributed RSA-Key Generation” in the upcoming Annual Symposium on 
Theory of Computing (STOC) ‘ 98 . 

Explicit Trust Distribution 

Transparency implies that the external environment providing the input/output to the 
protocol is transparent of the trust mechanism. This, however, is not always necessary 
(and may sometimes even be undesirable). But explicit trust mechanisms are designed 
with operations that are meant to be traced or followed explicitly (and not to remain 
hidden). The idea is that the trail of participants is noticeable in the result of the proto¬ 
col, a property that may be desirable. In some cases, for instance, instead of using 
threshold RSA techniques, using one signature by each CA entity may be the simplest 
and most appropriate technique. 
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Network Flight Recorder 

Network Flight Recorder (NFR) is the 
latest venture by Marcus Ranum, security 
guru of the first order, and his associates. 
NFR is, simply put, a network sniffer and 
processing language that hooks into a 
Java GUI to display results. Data from the 
sniffer is saved to files that the Java GUI 
allows you to query. 

Anyone who has been around the back 
end of a network late at night, either 
trying to fix the network or trace an in¬ 
truder, knows the value of network snif¬ 
fers. These are the debugging tools of 
choice for the network administrator, and 
historically they have been divided into 
two categories: network monitor/statis- 
tic-gatherer for use by network adminis¬ 
trators, and sensitive data sniffer for use 
by network intruders. NFR can be used 
in place of both tools and for a variety of 
other network administration jobs. 

The beauty and beast of NFR is that it is 
really a programming language for a net¬ 
work sniffer and display program. With 
NFR, you can extract any data off a 
TCP/IP network. But there is a catch: you 
probably have to write the program your¬ 
self. Future versions of NFR will support 
other network protocols as well. 

So why bother with NFR at all, you ask. 
The answer is easy: the language used 
(known as n-code) is pretty simple to 
pick up for anyone whos programmed in 
C or Perl. NFR now gives you a single 
interface, so you can finally put away all 
those shell scripts and tcpdump hacks 


you were using before. Finally, you have 
one tool to do all the network sniffing 
and analysis that you want. 

Background 

NFR is a series of programs that allow you 
to pull data off a network and display it in 
a Java-driven GUI. As its name implies, it 
is a network recorder and can be pro¬ 
grammed to grab as much, or as little, 
data off the network as you desire, so you 
can program it to ignore all the network 
“noise” that you are not interested in. 

NFR consists of four major pieces: 

1. packet sniffer, the program that 
actually listens to the network 

2. nf rd the daemon that manages and 
executes the n-code (filters), which is 
the heart of NFR 

3. back-end processors, which do the 
dirty work of actually taking the out¬ 
put of the filters (n-code programs) 
and recording the data into files that 
can then be queried (Currently only 
two types of data file formats exist: list 
and histogram.) 

4. GUI, A Java-based interface that allows 
you to query the files created by the 
back-end processors 

An alert daemon (alertd) and space 
management daemon also exist, but they 
are not really part of the NFR core. The 
alert daemon is used to send alerts 
(email, pager, fax, or print) when some¬ 
thing really big happens (you can define 
what really big is), and the space manage¬ 
ment daemon is there to rotate data files 
and prevent your hard drive from filling 
up if you are gathering a lot of data. 

These four pieces work together basically 
as follows. Data are captured by the snif¬ 
fer and passed to the nfrd. Nfrd checks 
the packet against currently installed fil¬ 
ters to see if it should be passed to a back 
end. If the data should be captured, the 
back end records the data to a file. 

Finally, when the user enters a query 
through the GUI, the data are retrieved 


from the appropriate file and displayed 
accordingly. 

According to the folks who make it, NFR 
is supposed to be a sort of Swiss army 
knife for the network administrator. The 
idea is that no one but you can really 
know what tool you’ll need today. So this 
generic tool is highly adaptable to the 
needs of a network administrator. What 
this really means is that NFR is supposed 
to be a highly programmable piece of 
software, which it is, and is not for the 
programming faint of heart or for those 
looking for a plug-and-play solution. 
What it also means is that if you under¬ 
stand what you want and can do some 
simple programming, you can make a 
wide variety of nifty tools for monitoring 
your network and its traffic. 

Like much of the work Mr. Ranum has 
done, NFR is available to the public for 
noncommercial use at <http://www.nfr.net>. 
As always, check the license for details on 
acceptable use. 

Competitors 

Many of the IDS (Intrusion Detection 
Systems) currently available are being 
compared to NFR. The problem with this 
comparison is that NFR is a generic tool 
that requires more networking knowl¬ 
edge and patience than many of the IDS 
on the market today. Often, therefore, the 
comparisons are apples to oranges. 

NFR (today anyway) is not an IDS. It can 
do IDS-like things if you want to program 
it that way, but it can also do a multitude 
of other things that most IDS do not do; 
it all depends on how you program it. 

NFR does come with a number of “built- 
in” programs that are useful, including a 
SMTP monitor, a Web server monitor, 
and a number of protocol monitors that 
let you watch packet/machine statistics. 

As far as I have seen (which may not be 
that much), there are not any direct com¬ 
petitors to NFR; it is just too generic and 
flexible a tool. However, for those looking 
for IDS tools, the market is getting larger. 
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Some IDS products are: Real Secure by ISS <http://www.iss.net>, 
Session Wall-3 by Abirnet <http://www.abirnet.com>, and NetRanger 
by Wheelgroup <http://www.wheelgroup.com> 

My NFR Experience 

Being as paranoid as I am, I love (as sick as that is) to know what 
exactly is happening on my beast of a network. The politics of 
monitoring network traffic aside, it is highly useful both from a 
security and a network management perspective to know exactly 
what your network is doing. 

My network (I call it that though many others have and do work 
on it more than I do now) consists basically of four segmented 
class C networks and an internal immutable class A network. The 
external networks have been separated into two specific zones: 
one for our clients and one for us (the good guys). Between each 
network lies a firewall with various rules. The firewalls are swap¬ 
pable and can be updated from a central point over a secure link. 
So if one firewall fails, we can always swap a backup in place in 
about five to ten minutes of failure. We believe in the old securi¬ 
ty-in-depth principle. Did I mention being paranoid ? 

Because we are currently evaluating NFR, we have only one host 
to compile, run, and test n-code applications. NFR is nonintru- 
sive, so it can sit and watch the network, carrying out three tasks: 

1. making sure that my firewalls are doing what they are sup¬ 
posed to be doing (i.e., a firewall consistency checker) 

2. watching inbound traffic for what I consider “bad traffic” 

(e.g., http requests for phf, popmail requests, etc.) 

3. gathering network statistics on type and volume of traffic 
throughout the day 

In the past, I have kludged together the invaluable tcpdump and 
some Perl scripts to regularly update me on the “health” of my 
network. I currently am replacing most of those “hacks” with n- 
code programs and then comparing how they perform. The 
main advantage so far has been that NFR enables me to have a 
single interface and log and alerts for all of the programs I was 
using before (NNstat, tcpdump, etc.). 

After getting approval (isn’t that always the fun part), my plans 
involve setting up multiple NFR hosts on separate segments and 
having those hosts “ship” back the data to a central host via a 
secure channel. Each host will have the capability of sending 
email and paging an on-call administrator if a critical “error” 
occurs. This way I hope to obtain the redundancy and network 
coverage of having multiple hosts while maintaining a central 
point for logging and statistics gathering. 

Some simple examples of code 

Anyone who’s written C or Perl will be able to recognize and 
understand n-code fairly easily. If you don’t have previous pro¬ 
gramming and networking experience, you probably shouldn’t be 
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touching NFR. I’ll assume you have managed to install NFR and 
check out some of the sample programs they’ve made available. 

To write a program in n-code you must have three basic files: 
program . nf r, program . cf g, and program . desc. 

Programs (a.k.a. filters) are usually placed in a directory to 
group programs together, so programs testl, test2, and test3 go 
in the test directory, etc. To ensure that this directory structure is 
passed on to the interface, a config file for each directory (i.e. 
group) is created. 

For our test code, I’ll make a test directory and create a 
test.cfg file. So if I do an Is I have the following files: 

packages> Is 

test/ 

test.cfg 

and the test.cfg file looks like 

packages>cat test.cfg 

############################### 

# 

# Test 

# By C.Lalonde Ingenia 

# Communications Corp 

# 

enabled=true 

# allow NFR to start itself 
title= Test verO.O 

# the title that will appear 
#end 

############################### 

This is the base config I use when testing some new applica¬ 
tion. Comments in all files have a “#” sign in front of them. You 
don’t have to include so many comments; I’m just being a good 
coder for this one example. 

Once you have a directory and the directory config file, you 
now have to create the three files needed to create a filter. So if I 
cd into the test directory shown above and do an Is, I’ll see 
the following: 

packages>cd test 
packages/tes t>Is 
testl.nfr 
testl.cfg 
testl.desc 

Files ending with a .nfr extension are the actual nfr code: the 
guts and glory. Files ending with .cfg extensions supply the 
interface configuration information for each program, and files 
ending with .desc are plain text descriptions of what your code 
is supposed to do. 

NFR is like C in its semantics but like Perl in its variable imple¬ 
mentation. .nfr programs are loaded at run time and only actu¬ 
ally “work” when a “trigger” is pulled. A trigger can be almost any 
network event, from all TCP traffic to a highly specific event (e.g., 
when you see the string phf coming from a client to a server on 
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Capturing HTTP GET Requests 

Here’s a simple piece of n-code that records all http GET 
requests. All requests should take the form of: 

Method SP Request-URI SP HTTP-Version CRLF 
(e.g., GET /index.html HTTP/l.O) 

What we are telling NFR to do with the following code is to, 
first, look only at data sent or received on port 80, second, start 
recording only when you see the string GET, and, third, stop 
recording when you see the string HTTP/. 

If you wanted to record all POST or HEAD requests, you would 
simply modify the piece of the code that says start: GET to start: 
POST etc. 

This is likely the simplest method of recording request types or 
any string and can be a little error prone (because not every 
implementation of the HTTP protocol is the same). 

>cat test2.nfr 

################################################# 

# 

# test2 

# By C. Lalonde Ingenia Communications Corp 
################################################# 

# 

# 

# record all http GET requests 

# March/13/98 

################################################# 

# 

test2_schema = [1, 1, 6, 6, 2 ] ; 

filter urlcatcher tcp( port: 80, start: "GET", 
stop:"HTTP/" ) { 

# port: - record data from/to this port 

# start: - start recording data when we receive 

# this string 

# stop: - stop recording when we receive this 

# string 

record packet.sec, ip.src, ip.dst, tcp.bytes to 
RECORDER_TEST; 

# tcp.bytes - where the recorded data is stored 

} 

RECORDER_TEST = recorder ("bin/histogram 

packages/test1/test2.cfg", "test2_schema"); 

Note: As you can see from the placement of the .cfg file in the 
above recorder statement, I have not created another directory. I 
am simply adding another n-code application to the same testl 
directory structure that I used for my previous example. 


>cat test2.cfg 

unnmmnunumunummmuummuMM 

# 

# By C.Lalonde Ingenia Communications Corp. 

# 

################################################ 

# Test2 vO.O 

# 

enabled=true 

# allow nfrd to load this 
gui=list 

# what type of gui should we display (two types 

# are list and 

# histogram) we've said that data would be saved 

# as type list in 

# the testl.nfr file so we have to say list here 
num_columns=3 

# number of columns of data we're going to 

# display 

# variable types for each column in the display 
co lumn_l_type=p_s r c_ip 

column_2_type=p_ds t_ip 
co lumn_3__t ype=p_s t r i ng 

# titles you will see for each column in the 

# display 

column_l__label=Source IP address 
column_2_label=Destination IP address 
column__3__label=GET URI 

rollover=300 
modified=true 

orgin=C.Lalonde Ingenia Communications Corp 
title=Test2 ver 0.0 

# title we're going to see 

cfversion=l 

# version number 

rollover_size=YES 

# are we going to roll over the data for size ? 

rollover jsize_val=1024000 

# at what size do we roll it over 

# pretty small since this is a test and we're 

# recording everything 

r ollover_time=YES 

# are we going to roll over the data for time ? 

roll over _t ime_va1=300000 

# how frequently 

archive_path=data/%p/%b/%y/%m%d/ 

# where to archive the data 


>cat test2.aesc 

N-code to record all http GET requests 
# By C.Lalonde Ingenia Communications Corp. 
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port 80). Once set in motion, the program can record ail the data 
and do other nifty things, like send email or call a pager. 

Here is a simple program called testl.nfr that records all TCP 
traffic: 

packages>cat testl.nfr 

################################################## 

# testl 

# By C. Lalonde Ingenia Communications Corp 
################################################## 

# 

# Test program to see what this puppy can do 

# 

# Jan/26/98 

################################################## 
testl_schema = [ 1, 1, 1, 1, 6, 6 ]; 
filter testl tcp( ) { 

record packet.sec, tcp.sport, tcp.dport, ip.src, 
ip.dst to RECORDER_TEST; 

} 

RECORDER_TEST = recorder {"bin/list 
packages/testl/testl.cfg", 

"testl_schema") ; 

# 

# end 

################################################## 

Now I’m going explain what the above says, line by line. 

testl_schema = [1, 1, 1, 1, 6, 6]: 

- A schema describes the data types to nf rd and how they 
should be recorded, in this case: 

1 - int - system.time 

1 - int - packet.sec 

l - int - source port 

1 - int - destination port 

6 - ipv4 addr - source ip address 

6 - ipv4 addr - destination ip address 

filter testl tcp{){ 

- Begin testl filter recording tcp packets. 

record packet.sec, tcp.sport, ip.src, tcp.dport, 
ip.dest to RECORDER_TEST 

- This is the record statement. In this case, I’m recording a hash 
of the tcp connection, the source ip port, the source ip address, 
the destination ip port, and the destination ip address to the 
recorder recorder_test. 

RECORDER_TEST = recorder ("bin/list packages/ 
testl/testl.cfg", "testl_schema") 

- This is the definition of the variable recorder_test. In this 
case, I’m saying that RECORDER_TEST is a recorder of type list, 
and NFR should check the files testl. cfg for details on how to 
show the data sent to this variable and testi_schema for details 
on how to record the data sent to this variable. 


Now that we know the basics of the . nf r file, we’ll move along 
to the . cfg files. As we have seen, the . cfg files tells the nfrd 
how to display the information passed to it. A simple conf ig file 
looks like: 

packages/test>cat testl.cfg 
# 1 ^#########^#################################### 

# 

# By C.Lalonde Ingenia Communications Corp. 

# 

################################################ 

# Testl vO.O 

# 

enabled=true 

# allow nfrd to load this 
gui=list 

# what type of gui should we display (two types 

# are list and histogram) we've said that data 

# would be saved as type list in the testl.nfr 

# file so we have to say list here 

num_columns=4 

# number of columns of data we're going 

# to display 

# variable types for each column in the display 
col umn_l_type=p_s r c_po r t 

co lumn_2_ty pe=p_ds t_por t 
col umn_3_type=p_s r c_ip 
col umn_4_type=p_ds t_ip 

# titles you will see for each column in 

# the display 

column_l_labe 1=Source port 
column_2_label=Destination port 

column_3_1abe1=Source IP address 

column_4_label=Destination IP address 

rollover=300 
modified=true 

origin=C.Lalonde Ingenia Communications Corp 
title=Testl ver 0.0 

# title we're going to see 

cfversion=l 

# version number 

rollover_size=YES 

# are we going to roll over the data for size ? 
rollover_size_val=1024000 

# at what size do we roll it over 

# pretty small since this is a test and we're 

# recording everything 

rollover_time=YES 

# are we going to roll over the data for time ? 

rollover_time_val=300000 

# how frequently 

archive_path=data/%p/%b/%y/%m%d/ 

# where to archive the data 

# 

# end 

################################################ 
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The . cfg file for a program is very similar to that of the directo¬ 
ry . cfg file. The comments in the file should be enough to get 
you started. 

Now we’ve got two of the three basic; the other file isn’t really 
required, but it is usually included for completeness. So 
testl.desc looks something like this: 

packages/test>cat testl.desc 

################################################ 
This is a Test program which records all tcp 

# packets. 

# 

# By C. Lalonce Ingenia Communications Corp. 

# 

# end 

############################################### 

The .desc file is simply a description file included to allow for 
explanatory comments. 

Now we have all three files, and they are sitting in the correct 
directory. The best thing to do is quickly check your testl .nfr 
with the handy test-nfra program. Simply type test-nfrd 
testl .nfr and if you have any syntax errors, the entire program 
will be displayed and the errors will be surrounded with >><< 
symbols. 

Next start NFR as the documentation instructs, and check to see 
if it works. 

A good place to start looking/learning about the programs is to 
review the examples included with NFR and have a read through 
the documentation. There are many excellent examples, and they 
are well documented. 

Negative Aspects of NFR 

Don’t even think about running NFR on a machine with less 
than 64MB of memory, especially on busy networks. Programs 
that use the histogram type seem to use more memory, so try 
sticking with list-based programs if you can and remove any 
programs you are not using. You can do this by simply moving 
the directory and files associated with that program directory up 
one level. For example: 

packages>Is 

test/ 
test.cfg 

packages>mv test* .. 

Packages can also be disabled via the GUI or changing 

enable=true to enable=false in the appropriate config file. 

As with any new programming language, it is difficult to jump 
right in and start programming in n-code. Although NFR has 
made a large effort to aid beginners in overcoming their initial 
difficulties and hesitations, improvements could still be made. 


The NFR system and n-code are not for the faint of heart; but 
they will be much easier for those who understand network pro¬ 
tocols and what data they want to record. 

My biggest complaint about NFR to date is the documentation. 
Currently, there are several shortcomings, the biggest being top¬ 
ics that are not covered (e.g., the“schema= [1,1, 6,6,2]” defini¬ 
tion is not covered anywhere except in the sample code, and 
there only briefly). 

Secure Networks Inc. recently published a technical paper that 
outlines problems inherent in using Intrusion Detection Systems 
based on network sniffing. It outlines a number of problems 
with various IDS and once again shows that “there is no silver 
bullet.” This paper is definitely worth reading. You can find the it 
at <http://www.securenetworks.com/papers/ids-html/>. 

Positive Aspects of NFR 

Flexibility will be NFR’s key to success. I have yet to come across 
a tool that allows me to do such a variety of tasks while main¬ 
taining a consistent look and feel with the Java GUI. From alert¬ 
ing network administrators to break-ins, network overloads, and 
other strange occurrences to building a database of network 
activity for statistical analysis to tracking specific traffic from a 
specific machine, NFR and n-code have the flexibility to do it all. 

If you’re interested in trying it out, subscribe to the NFR mailing 
lists. I hey give you direct access to the actual developers (what 
an amazing thing this is), and the response time has been excel¬ 
lent. You can actually talk to the developers and possibly have an 
effect on the product. This access to the developers has been key 
in overcoming the problems I have had with the documentation. 

The potential for NFR on a network is huge. Why? Picture sever¬ 
al connected NFRs providing a “web” of network analysis and 
security monitors at a fairly reasonable cost. Also, it would be 
custom built for your network to be tailored to your specific 
needs. NFR is easily expandable in that you could start with one 
or two NFRs and easily connect more as load and network 
growth require. Finally, all the “monitors” can be controlled and 
configured from a central point, allowing easy maintenance. 

Conclusions and Future Directions 

NFR is a highly useful tool for any network administrator. Like 
anything new, it has an initial learning curve and some software 
problems to work out. 

Whatever NFR’s future, it is not an IDS, not exclusively anyway. 
You can make NFR an IDS, but that does not seem to be the 
only design goal. Additionally, with the increase of protocols and 
platforms supported (an NT version is due out sometime in the 
early summer, along with support for Novell, or so the NFR 
team hints), NFR continues to expand its usefulness on today’s 
multiprotocol and multiplatform networks. 
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I SAGE Security Handbook 
Sorts Through Security 
Approaches 

i n k ii . . .• 


If you are in the trenches maintaining security, help your managers understand the 
big picture. Buy a copy and pass it along to your managers. 

Security is, more than anything else, a way of thinking. Managers of IT need to know 
how to think the “security way” in order set a “just enough” security policy, to know when 
to use which tool, or to evaluate sagely the claims of vendors. Here’s a very practical, very 
short handbook which details what you as an educated consumer of security need to 
understand-without getting bogged down in technical detail. 

System Security: A Management Perspective 

by David L. Oppenheimer, David A. Wagner, and Michele D. Crabb 
Edited by Dan Geer 

Contents 

■ Threats and Responses 

■ Financial Considerations and Risk Management 

■ Trust Models 

■ Security Policies and Procedures: The Roadmap 

■ The Orange Book 

■ Putting It All Altogether 

■ Appendix A: The Top Ten Computer Security Problems 

■ Appendix B: Useful Computer Security Resources 

The third and newest in the Short Topics in System Administration series 
published by SAGE,, the System Administrators Guild. 

Already published: 

■ Job Descriptions for System Administrators, edited by Tina Darmohray 

■ A Guide to Developing Computing Policy Documents, edited by Barbara L. Dijker 
Forthcoming booklets are on education and training for system administrators, 
hiring and interviewing sysadmins, and legal issues in system administration. 


Order by email to office@usenix.org or 
fax to 510 548 5738. 

■ $5.00 for SAGE members 

■ $7.50 for non-SAGE members 

■ Add $3.50 per order to ship overseas ffitarmS 


"An excellent starting point.Jhe 
book is written so that both system 
administrators and their manage¬ 
ment can begin to understand the 
threats and solutions that can be 
applied to systems connected to the 
Internet." 

Katherine T. Fithen 
CERT Coordination Center 
Networked Systems Survivability 
Program 

"Offers a nice birds-eye view.Jhe 
explanations are clear, concise and 
to the point. I highly recommend 
that all IT managers get their hands 
on this book as soon as possible." 

Avi Rubin, AT&T Research Labs 

"Effective security requires strong 
management-level support, which in 
turn requires management-level 
understanding of the considerations. 
In 91 well-written pages, System 
Security does an outstanding job of 
explaining those considerations in a 
non-technical, management-oriented 
fashion." 

Brent Chapman 

Great Circle Associates , Inc. 




Announcement and Call for Papers 



8th USENIX Security Symposium 

Sponsored by USENIX in cooperation with The CERT Coordination Center 


August 23-26,1999 


Marriott Hotel, Washington, D.C. 


Important Dates for Refereed Papers 

Paper submissions due: March 16, 1999 
Author notification: April 21, 1999 
Camera-ready final papers due: July 12, 1999 
Registration materials available: May, 1999 

Conference Organizers 

Program Chair 

Win Treese, Open Market, Inc. 

Program Committee 

Fred Avolio, Trusted Information Systems, Inc. 

Crispin Cowan, Oregon Graduate Institute 
Jim Duncan, Pennsylvania State University 
Carl Ellison, CyberCash 
Dan Geer, CertCo 

Peter Gutmann, University of Auckland 
Trent Jaeger, IBM 
Wolfgang Ley, DFN-CERT 
Peter Trei, Security Dynamics, Inc. 

Dan Wallach, Princeton University 
Invited Talks Coordinator 
Avi Rubin, AT&T Labs - Research 

Overview 

The USENIX Security Symposium brings together 
researchers, practitioners, system administrators, system 
programmers, and others interested in the latest advances 
in security and applications of cryptography. 

This symposium will last for four days. Two days of 
tutorials will be followed by two days of technical sessions 
including refereed papers, invited talks, works-in-progress, 
and panel discussions. 

Tutorials, Mon. and Tues., August 23-24 

Tutorials for both technical staff and managers will 
provide immediately useful, practical information on 
topics such as local and network security precautions, 
what cryptography can and cannot do, security 
mechanisms and policies, firewalls and monitoring 
systems. 


If you are interested in proposing a tutorial, contact the 
tutorial coordinator, Dan Klein, by phone at 
+ 1.412.422.0285 or by email to dvk@usenix.org. 

Technical Sessions, Wed. and Thurs., August 25-26 

In addition to the keynote presentation, the technical 
program includes refereed papers, invited talks, a Works- 
in-Progress session, and panel discussions. There will be 
Birds-of-a-Feather sessions both evenings. You are invited 
to make suggestions to the program chair via email to 
securitychair@usenix.org. 

Papers that have been formally reviewed and accepted 
will be presented during the symposium and published in 
the symposium proceedings. The proceedings are 
provided free to technical session attendees. Additional 
copies will be available for purchase from USENIX. 

Symposium Topics 

Refereed paper submissions are being solicited in areas 
including but not limited to: 

Adaptive security and system management 
Analysis of malicious code 
Applications of cryptographic techniques 
Attacks against networks and machines 
Authentication and authorization of users, systems, and 
applications 

Detecting attacks, intrusions, and computer misuse 
Developing secure systems 
File and file system security 
Network security 
New firewall technologies 
Public key infrastructure 
Security in heterogeneous environments 
Security incident investigation and response 
Security of agents and mobile code 
Technology for rights management and copyright 
protection 

World Wide Web security 

Note that this symposium is not about new codes, 
ciphers, nor cryptanalysis for its own sake. 




How to Submit a Refereed Paper 

Papers should represent novel scientific contributions in 
computer security with direct relevance to the engineering 
of secure systems for the commercial sector. 

Authors must submit a mature paper in PostScript 
format. Any incomplete sections (there shouldn't be 
many) should be outlined in enough detail to make it 
clear that they could be finished easily. Full papers are 
preferred, and should be about 8 to 15 typeset pages. 
Submissions must be received by March 16, 1999. 

Along with your paper, please submit a separate email 
message in ASCII containing the title, all authors, and 
their complete contact information (phone, fax, postal 
address, email). Please indicate which author is the 
contact author and indicate any authors who are full-time 
students. 

Authors will be notified of acceptance on April 21, 

1999. 

All submissions will be judged on originality, relevance, 
and correctness. Each accepted submission may be 
assigned a member of the program committee to act as its 
shepherd through the preparation of the final paper. The 
assigned member will act as a conduit for feedback from 
the committee to the authors. Camera-ready final papers 
are due on July 12, 1999. 

If you would like to receive detailed guidelines for 
submission, you may telephone the USENIX 
Association office at 510.528.8649 or send email to 
securityauthors@usenix.org. 

The Security Symposium, like most conferences and 
journals, requires that papers not be submitted 
simultaneously to another conference or publication and 
that submitted papers not be previously or subsequently 
published elsewhere. Papers accompanied by non¬ 
disclosure agreement forms are not acceptable and will be 
returned to the author(s) unread. All submissions are held 
in the highest confidentiality prior to publication in the 
Proceedings, both as a matter of policy and in accord with 
the U.S. Copyright Act of 1976. 

Specific questions about submissions may be sent to the 
program chair via email to securitychair@usenix.org. 

Best Paper Awards 

Awards will be given for the best paper and best paper by 
a student at the conference. 


Where to Submit 

For reliability, please send one copy of your paper to the 
program committee via both of the following two 
methods. All submissions will be acknowledged. 

• Email (PostScript) to: securitypapers@usenix.org 

• Send a hard copy to: 

USENIX - Security Symposium 
2560 Ninth St., Ste. #215 
Berkeley CA 94710 U.S.A. 

Phone: 510.528.8649 

Vendor Displays 

Demonstrate your security products to our technically 
astute attendees responsible for security at their sites. Meet 
with attendees in this informal setting and demonstrate in 
detail your security solutions. We invite you to take part. 
Contact: 

Cynthia Deno 

Email: cynthia@usenix.org 

Phone: 408.335.9445 • Fax: 408.335.5327 

Works-in-Progress Session (WIPs) 

The last session of the symposium will be a Works-in- 
Progress session consisting of five-minute presentations. 
Speakers should provide a one or two paragraph abstract 
to the program chair by 6:00 pm on Wednesday, August 
25, 1998. These should be provided in person at the 
conference, not via email. The chair will post the schedule 
of presentations by noon on August 26. Experience at 
other conferences has shown that usually all of them are 
accepted. The five-minute time limit will be strictly 
enforced. 

Invited Talks 

There will be several invited talks at the conference in 
parallel with the refereed papers. If you have suggestions 
for possible speakers, please send them to 
security-it@usenix.org. 

Registration Materials 

Materials containing all details of the technical and 
tutorial programs, registration fees and forms, and hotel 
information will be available late May, 1999. To receive 
printed registration materials, please contact: 

USENIX Conference Office 

22672 Lambert Street, Suite 613 

Lake Forest, CA USA 92630 

Phone: 714.588.8649 • Fax: 714.588.9706 

Email: conference@usenix.org 


USENIX®, the Advanced Computing Systems Association 


This Call for Papers can be found on the USENIX Web site at http://www.usenix.org/events/sec99/cfp.html 






TECHNOLOGY 
AND PRIVACY 

The New Landscape 

edited by Philip E. Agre 
and Marc Rotenberg 
“Commerce, bandwidth, equity of access, 
copyright—these are some of the battles that are 
taking place in the Internet environment, but the one 
that will affect all of us is the battle over privacy. 
Technology and Privacy is an excellent survey of the 
different issues on the different fronts. This is 
important reading for journalists, legislators, 
activists, and citizens." — Steve Cisler, 

Advanced Technology Group, Apple Computer 
“(These essays are] brilliant and clearly written. They 
offer the most innovative thinking about this issue in 
a decade and a half. Agre truly moves the privacy 
debate ahead...a significant new contribution to the 
privacy debate, even among professionals who deal 
with these issues regularly." — Robert Ellis Smith, 
Publisher, Privacy Journal 
280 pp., 13 illus. $25 

original in paperback 

COORDINATING 
THE INTERNET 

edited by Brian Kahin and James H. Keller 
Once entirely built and supported by the U.S. 
Government, the Internet is now remarkably 
decentralized and uninstitutionalized. Its future is 
not tied to any particular organization, but as it 
grows in scope, bandwidth, functionality, and 
“internationality," it will require greater coordination. 
At the moment it is not clear what kind of coordinat¬ 
ing mechanisms and institutions will evolve. 

Problems discussed in this book include network 
address allocation and the management of domain 
names, intellectual property, and finances. 

Solutions explored range from bilateral and universal 
agreements between nations to consensual 
standards negotiated in the open market. 

A publication of the Harvard Information 
Infrastructure Project 
500 pp. $25 paper 


iWarp 


Anatomy of a Parallel 
Computing System 

Thomas Gross and David R. O'Hallaron 
“There is no doubt that iWarp was an important 
research effort. This work is significant as an 
archival record of the innovative research under¬ 
taken in the iWarp project." —Siddhartha Chatterjee, 
University of North Carolina at Chapel Hill 
The iWarp is an experimental parallel system 
designed and built jointly by Carnegie Mellon 
University and Intel Corporation. This book 
describes the complete iWarp system, from 
instruction-level parallelism to final parallel 
application. The authors present a range of issues 
that must be considered to get a real system into 
practice, and also provide a start-to-finish history of 
the project, including what was done right and what 
was done wrong. 

530 pp., 270 illus. $45 



USENIX members receive a 15% discount 
on the following MIT Press publications: 


SOFTWARE 

AGENTS 

edited by Jeffrey M. Bradshaw 
A comprehensive survey of the state of the art in the design 
and use of intelligent software agents and in the creation of 
communication ability between agents. The book presents the 
views of proponents and critics of software agents, describes 
how agents are used to enhance learning and provide 
intelligent assistance to users in situations where traditional 
direct manipulation interfaces alone are insufficient, and 
discusses agent-to-agent communication and the use of 
agents to provide intelligent interoperability in distributed 
systems and the Internet. 

450 pp. $40 paper 

THE EVOLUTION 
OF C++ 

Language Design in the 
Marketplace of Ideas 

edited by Jim Waldo 

This collection of articles traces the history of C++ from its 
infancy in the Santa Fe workshop, to its proliferation today as 
the most popular object-ortiented language for microcomput¬ 
ers. Waldo notes in his postscript that in the process of 
evolving, the language has lost a clearly articulted, generally 
accepted design center, with no common agreement about 
what it should or should not do in the future. 

279 pp. $27.50 paper 

A WORLD’S FAIR 
FOR THE GLOBAL 


VILLAGE 


Carl Malamud 

foreword by His Holiness The Dalai Lama 

afterword by Laurie Anderson 

“Malamud shows us the potential of our digital technology 

to link us together in new ways that develop both our 

imagination and spirit. This is a work of both elegance 

and vision." — Tom Lewis, Author, Empire of the Air 

“It is projects like the World's Fair that can really excite as all 

its unbridled enthusiasm and optimism crash through old 

tenacious information barriers." — Peter Gabriel 

304 pp., 800 color illus. $40 

now in paperback 

INTERNET 

DREAMS 

Archetypes, Myths, and Metaphors 

Mark Stefik 

“Clever juxtapositioning of essays wrapped in the author's 
insightful commentary paints a telling picture: the Internet is 
unique, yet the policies that shape its design and use are 
often influenced by the metaphors that we ascribe to 
it.../nfemef Dreams is not just a philosophical argument, but a 
valuable history (and prehistory) of the Net. In fact, no other 
book that I'm aware of portrays the philosophical development 
of the Internet with such depth and perspective."— Byte 
440 pp., 24 illus. $15 paper 




_The MIT Press • Five Cambridge Center • Cambridge. MA 02142-1399 USA 


To order by phone, call 800-356-0343 (US & Canada) or (617) 625-8569. http://mitpress.mit.edu 

E-mail o rde rs: m itpress-orders@mit.edu • The operator will need this code: UNIX1 







MORGAN KAUFMANN PUBLISHERS, INC. 

On the C utting E dge of T echnology 



Understanding UML 
The Developer's Guide 

By Paul I larmon & Mark Watson 
1997, 380 pages, paperback. 
ISBN 1-55860465-0. S32.95 


Advanced Compiler Design 
Implementation 

By Steven S. Muehnick 
1997. 885 pages, cloth. 
ISBN 1-55860-320-4. S89.95 


Creating JavaBcans: Components 
for Distributed Applications 

By Mark Watson 
1997. 253 pages, paperback. 

ISBN 1-55860-476-6. S29.95 



Switching in IP Networks: IP Switching, 
Tag Switching, and Related Technologies 

By Bruce Davie, Paul Poolan, & Yakov Rekhtcr 
May 1998.344 pages, paperback, 

ISBN 1-55860-505-3. S44.95 


BeOS: 

Porting 

UNIX 

Applications 


Martin C, Brown 


BeOS 

Porting Unix Applications 

By Martin C. Brown 
July 1998,500 pages, paperback, 
ISBN 1-55860-532-0, S36.95 

Also Forthcoming: 

Inside the BeOS 
File System Design 
By Dominic Giampolo 
Fall 1998, 250 pages, paperback, 
ISBN 1-55860-497-9 


Optical Networks 
A Practical Perspective 

By Rajiv Ramaswatni & Kumar Sivarajan 
1998. 656 pages, cloth. 

ISBN 1-55860-445-6, S69.95 



Digital Compression for Multimedia 
Principles & Standards 

By Jerry D Gibson, Toby Berger, Tom Lookabaugh, 
Dave Lindbergh, & Richard L. Baker 
1998.493 pages, cloth. 

ISBN 1-55860-369-7,74.95 


Morgan Kaufmann Publishers, Inc. 

Mail: 340 Pine Street, 6th Floor, San Francisco, CA94104 
Phone: (415) 392-2665 or (800) 745-7323 Fax: (415) 982-2665 
Email: orders@mkp.com Web: http://www.mkp.com 
Also available at vour local bookstores! 



15 % Discount 


to Usenix Members! 



Please mention Code SLOl when ordering. 
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WindowsNT 

security Breaches are 

inside jobs. 


SHVTRY r aiTfflPRISE 

EVENT MANAGER SeNTVy - the Enterprise 
Event Manager (EEM) moves critical event log data to 
a secure location and alerts you to unusual activities. 


S' ENTERPRISE 

ADMINISTRATOR Enterprise Administrator (EA) 
allows you to reduce the number of all-powerful Windows 
NT administrator IDs. 


SeNTry EEM immediately notifies you, by pager or e-mail, of events 
that you consider important. SeNTry EEM provides a central monitor 
that enables you to view one filtered, consolidated, time-ordered 
subset of all the events you choose to monitor from 100s to 1000s of 
Windows NT servers and workstations. 



The SeNTry 
EEM monitor 
allows you 
to view all 
Windows NT 
servers with 
red alerts 
for quick 
identification 
of security 
events that 
you consider 
important. 


You can monitor security event logs, application event logs, 
system event logs, IIS logs, SQL Server Trace log files, and even 
SNMP traps. You decide what data to view, so you see only what 
is critical to you such as security policy changes, assignment of 
special privileges, and use of unauthorized files. Most importantly, 
this filtered data is saved to an ODBC-compliant database, so you 
have a permanent record of security breaches or any other 
suspicious activity on the machines monitored throughout your 
organization. SeNTry EEM also provides comprehensive reports 
for easy access and analysis of the data. 


With EA, you can reduce risk, improve audit controls, and respond 
more quickly to end-users. Deputy administrators perform routine 
administrative tasks without having the unlimited access provided 
by a Windows NT administrator ID, but with every action securely 
logged. EA also gives you powerful security tools, such as password 
strength policy enforcement, naming convention enforcement, 
comprehensive last logon statistics, and dual-key security for sensi¬ 
tive actions. The EA "Power tools" reduce the amount of time spent 
on repetitive tasks, while maintaining full security. 



With Enterprise 
Administrator, 
you decide who 
has administrative 
authority over 
what resources 
and how much 
power they 
possess. 

Devgned fpf 




Microsoft ’ 

BackOffice- 


EA's advanced administration environment provides the tools and 
reports your organization needs to administer a large-scale Windows 
NT network efficiently, responsively, and securely. By automating 
administrative tasks, EA will help you increase the productivity and 
accuracy of your Windows NT administration activities. 

Find out how to secure your Windows NT network. 

Contact Mission Critical Software at: 1-888-323-6768 
or 1-713-548-1700. 



Whether it’s an employee 
covering his trail or one making 
an honest mistake, SeNTry 
EEM keeps a permanent record. 


MISSIONCRITICAL 


software 


secure.missioncritical.com 


© 1998 Mission Critical Software. Inc.; all rights reserved. 

Mission Critical Software, the Mission Critical Software logo. MCS. Enterprise Administrator, the Enterprise Administrator Logo. EA. SeNTry - the Enterprise Event Manager, 
the SeNTry - the Enterprise Event Manager Logo, SeNTry. and EEM are trademarks of Mission Critical Software. Inc. in the United States and other jurisdictions. 































































CONNECT WITH USENIX 



HHH 










MEMBERSHIP AND PUBLICATIONS 

USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
Phone: 510 528 8649 
FAX: 510 548 5738 
Email: <office@usenix.org> 

WEB SITE 

http://www.usenix.org 

AUTOMATIC INFORMATION 
SERVER 

If you do not have access to the Web, 
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CONTRIBUTIONS SOLICITED 

You are encouraged to contribute articles, book reviews, 
and announcements to ;login:. Send them via email to 
<login@usenix.org> or through the postal system to the 
Association office. 

Send SAGE material to <tmd@usenix.org>. The 
Association reserves the right to edit submitted material. 
Any reproduction of this magazine in its entirety or in 
part requires the permission of the Association and the 
author(s). 

The closing dates for submissions to the next 
two issues of ;login: are June 9 r 1998 
and August 11,1998. 
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